From: Alexei Starovoitov <ast@plumgrid.com>
To: Daniel Borkmann <daniel@iogearbox.net>,
"Devon H. O'Dell" <dho@fastly.com>
Cc: davem@davemloft.net, edumazet@google.com, netdev@vger.kernel.org
Subject: Re: [PATCH net-next] bpf, skb_do_redirect: clear sender_cpu before xmit
Date: Fri, 9 Oct 2015 20:19:39 -0700 [thread overview]
Message-ID: <561883CB.4030808@plumgrid.com> (raw)
In-Reply-To: <5617FA5A.9090406@iogearbox.net>
On 10/9/15 10:33 AM, Daniel Borkmann wrote:
>> 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.
since this bug wasn't fixed at once in all places, it means
that it is hard to review _all_ needed call-sites.
There are 7 places that call skb_sender_cpu_clear() in net-next.
Plus 2 more in net.
How many such paths from rx to tx left?
On the first glance ovs is missing one and who knows what else.
next prev parent reply other threads:[~2015-10-10 3:19 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-07 8:16 [PATCH net-next] bpf, skb_do_redirect: clear sender_cpu before xmit Daniel Borkmann
2015-10-07 15:46 ` Alexei Starovoitov
2015-10-09 0:50 ` Devon H. O'Dell
2015-10-09 2:35 ` Alexei Starovoitov
2015-10-09 16:40 ` Devon H. O'Dell
2015-10-10 3:11 ` Alexei Starovoitov
2015-10-09 17:33 ` Daniel Borkmann
2015-10-10 3:19 ` Alexei Starovoitov [this message]
2015-10-10 4:38 ` Eric Dumazet
2015-10-10 4:55 ` Alexei Starovoitov
2015-10-10 4:56 ` Alexei Starovoitov
2015-10-10 17:12 ` Eric Dumazet
2015-11-16 18:07 ` Eric Dumazet
2015-10-08 12:07 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=561883CB.4030808@plumgrid.com \
--to=ast@plumgrid.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dho@fastly.com \
--cc=edumazet@google.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).