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
| ||
|
Message-ID: <1271946271.7895.5631.camel@edumazet-laptop> Date: Thu, 22 Apr 2010 16:24:31 +0200 From: Eric Dumazet <eric.dumazet@...il.com> To: Changli Gao <xiaosuo@...il.com> Cc: David Miller <davem@...emloft.net>, hadi@...erus.ca, therbert@...gle.com, netdev@...r.kernel.org Subject: Re: [PATCH v5] net: batch skb dequeueing from softnet input_pkt_queue Le jeudi 22 avril 2010 à 20:27 +0800, Changli Gao a écrit : > On Thu, Apr 22, 2010 at 5:43 PM, David Miller <davem@...emloft.net> wrote: > > From: Changli Gao <xiaosuo@...il.com> > > Date: Thu, 22 Apr 2010 17:09:17 +0800 > > > >> + unsigned int input_pkt_queue_len; > >> + struct sk_buff *input_pkt_queue_head; > >> + struct sk_buff **input_pkt_queue_tailp; > >> + > > > > Please do not ignore Stephen Hemminger's feedback. > > > > We already have enough odd SKB queue implementations, we > > do not need yet another one in a core location. This makes > > it harder and harder to eventually convert sk_buff to use > > "struct list_head". > > > > Instead, use "struct sk_buff_head" and the lockless accessors > > (__skb_insert, etc.) and initializer (__skb_queue_head_init). > > > > If I want to keep softnet_data small, I have to access the internal > fields of sk_buff_head, and modify them in a hack way. It doesn't > sound good. If not, softnet_data will become: > > struct softnet_data { > struct Qdisc *output_queue; > struct list_head poll_list; > struct sk_buff *completion_queue; > struct sk_buff_head process_queue; > > #ifdef CONFIG_RPS > struct softnet_data *rps_ipi_list; > > /* Elements below can be accessed between CPUs for RPS */ > struct call_single_data csd ____cacheline_aligned_in_smp; > struct softnet_data *rps_ipi_next; > unsigned int cpu; > unsigned int input_queue_head; > #endif > unsigned int input_pkt_queue_len; > struct sk_buff_head input_pkt_queue; > struct napi_struct backlog; > }; > > Eric, do you think it is too fat? No it is not, as long as we are careful to separate cache lines. By the way, input_pkt_queue_len is already in input_ptk_queue (.len) Thanks -- 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