On Thu, Feb 26, 2015 at 8:51 PM, Willem de Bruijn [off-list ref] wrote:

On Thu, Feb 26, 2015 at 1:38 PM, Eyal Birger [off-list ref] wrote:

quoted

Hi,

On Thu, Feb 26, 2015 at 7:26 PM, Willem de Bruijn [off-list ref] wrote:

quoted

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?

I meant I prefer not to break out sockaddr_ll's individual fields in
packet_skb_cb.
Sorry for being ambiguous.

quoted

IMHO it would probably make sense to do it as part of your below suggestion.

quoted

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.

quoted

Thanks!
Eyal.