lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 22 Apr 2010 14:19:22 -0700 (PDT) From: David Miller <davem@...emloft.net> To: eric.dumazet@...il.com Cc: netdev@...r.kernel.org Subject: Re: [PATCH] NIU support for skb->rxhash From: Eric Dumazet <eric.dumazet@...il.com> Date: Thu, 22 Apr 2010 13:43:18 +0200 > Then, our stack also touch all 256 bytes of skb structure itself. > > offsetof(struct sk_buff, next) =0x0 > offsetof(struct sk_buff, rxhash) =0xa8 > offsetof(struct sk_buff, dev) =0x20 > offsetof(struct sk_buff, len) =0x68 > offsetof(struct sk_buff, protocol)=0x7e > offsetof(struct sk_buff, network_header)=0xc0 > offsetof(struct sk_buff, data) =0xd8 > offsetof(struct sk_buff, head) =0xd0 > > Time for a reordering I guess ;) Indeed. Also I have some ideas about what we can do if we have just the rxhash. It seems we can avoid the type_trans overhead on the interrupting cpu. Things like eth_type_trans() become a netdev operation rather than something drivers statically call by hand. ->ndo_type_trans or similar. SKB has a state bit saying whether ->ndo_type_trans has been invoked yet on RX. Drivers pass raw SKBs up into the stack. We defer the ->ndo_type_trans as far as possible, for RPS when we have ->rxhash we can defer this all the way to the destination RPS cpu. If we lack ->rxhash, the source cpu will need to invoke ->ndo_type_trans before it can begin parsing the packet. Anyways, something like that. -- 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