On Fri, 2015-10-09 at 19:33 +0200, Daniel Borkmann wrote: > On 10/09/2015 04:35 AM, Alexei Starovoitov wrote: > > On 10/8/15 5:50 PM, Devon H. O'Dell wrote: > >>> with the amount of skb_sender_cpu_clear() all over the code base > >>> >I wonder whether there is a better solution to all of these. > >> I think there is. We found that splitting the union of sender_cpu and > >> napi_id solved the issue for us. In general, I think this is an OK > >> solution as long as the following hold: > >> > >> * skbs are always allocated via kzalloc > >> * out -> out cloned skbs are always cloned on the same CPU > >> * an extra four bytes in skbuff isn't a bad thing > > > > I'm pretty sure extending sk_buff for this is not acceptable. > > +1, I agree. > > > I was thinking may be we can use sign bit to distinguish between > > napi_id and sender_cpu. > > Like: > > if ((int)skb->sender_cpu >= 0) > > skb->sender_cpu = - (raw_smp_processor_id() + 1); > > and inside get_xps_queue() use it only if it's negative. > > Then we can remove skb_sender_cpu_clear() from everywhere. > > Adding a check to napi_hash_add() to make sure that napi_id is not > > negative is probably ok too. > > Thoughts? > > I think this doesn't make it any more maintainable. > > skb_sender_cpu_clear(), one can at least git-grep to easily find > out and review call-sites in the code. There are various members > already used differently depending on the context.
Extending busy polling support for tunnels devices actually requires to make some changes in this area. We need to keep skb->napi_id set until skb reaches a socket, but skb_scrub_packet() currently defeats the thing. I will leave skb_sender_cpu_clear() in place but it will be empty. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
