[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+FuTSfNHsKjJPQZyp8pkohQM47sfFpv44=THk111+vKkZm_nA@mail.gmail.com>
Date: Thu, 26 Feb 2015 13:51:22 -0500
From: Willem de Bruijn <willemb@...gle.com>
To: Eyal Birger <eyal.birger@...il.com>
Cc: David Miller <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Shmulik Ladkani <shmulik.ladkani@...il.com>,
Marcel Holtmann <marcel@...tmann.org>,
Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 4/7] net: packet: use skb->dev as storage for skb
orig len instead of skb->cb[]
On Thu, Feb 26, 2015 at 1:38 PM, Eyal Birger <eyal.birger@...il.com> wrote:
> Hi,
>
> On Thu, Feb 26, 2015 at 7:26 PM, Willem de Bruijn <willemb@...gle.com> wrote:
>> On Wed, Feb 25, 2015 at 9:10 PM, Eyal Birger <eyal.birger@...il.com> wrote:
>>> As part of an effort to move skb->dropcount to skb->cb[], 4 bytes
>>> of additional room are needed in skb->cb[] in packet sockets.
>>>
>>> Store the skb original length in skb->dev instead of skb->cb[] for
>>> this purpose.
>>
>> Another option is to delay preparation of the full sockaddr_ll struct until
>> when it's needed. It often is not used at all (if msg_name == NULL).
>>
>> sll_family, sll_protocol and sll_pkttype can be derived when needed
>> in packet_recvmsg. The first two are the head of sockaddr_ll, so
>> a shorter struct filled in in packet_rcv only from sll_ifindex onwards
>> would save the 4B needed for origlen. Actually, a union is simpler:
>>
>> struct __packet_cb_sockaddr_ll {
>> union {
>> struct {
>> unsigned short sll_family;
>> __be16 sll_protocol;
>> }
>> unsigned int sll_origlen;
>> }
>> /* etc.. */
>> };
>>
>> The family and protocol can just overwrite sll_origlen in packet_recvmsg
>> before the memcpy into msg->msg_name.
>>
>
> That's an interesting option.
> My personal inclination is not to inline sockaddr_ll in the packet cb structure.
It already is, isn't it?
> IMHO it would probably make sense to do it as part of your below suggestion.
>
>> Also interesting would be to avoid copying the address in the fast path
>> as it may never be used, especially for long addresses (INFINIBAND_ALEN
>> and FWNET_ALEN). From what I can tell, all but one header_ops.parse
>> implementations return bytes from inside the packet, so could take an
>> unsigned char ** as argument, store that pointer and postpone the
>> memcpy to packet_recvmsg (handling skb_trim correctly). The exception is
>> fwnet_header_parse, which would require some workaround.
>
> I think it may be interesting to pursue this option, though I don't
> think it should
> be part of this specific effort.
Absolutely. This is a lot more work. Too much to fold into this patchset.
I was more speculating in general. I may look into this at some point.
>
> Thanks!
> Eyal.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists