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.
>
On Fri, 2015-10-09 at 21:56 -0700, Alexei Starovoitov wrote:
> yep. as I said it shouldn't be increased and proposed in-band sign bit.
I believe we still would like to keep some helpers to clearly identify
when a packet crosses domains. Even if the helper is empty.
It helps a lot when a new
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
On Fri, 2015-10-09 at 20:19 -0700, Alexei Starovoitov wrote:
> 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
On 10/9/15 9:40 AM, Devon H. O'Dell wrote:
I like the idea, but it seems unnecessarily magical. What about using
a bitfield? Then there's just an option bit that is either
OPTION_NAPI_ID or OPTION_SENDER_CPU. Then the check to set sender_cpu
in netdev_pick_tx becomes
if
On 10/9/15 9:38 PM, Eric Dumazet wrote:
On Fri, 2015-10-09 at 20:19 -0700, Alexei Starovoitov wrote:
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
On 10/9/15 9:38 PM, Eric Dumazet wrote:
On Fri, 2015-10-09 at 20:19 -0700, Alexei Starovoitov wrote:
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
On Thu, Oct 8, 2015 at 7:35 PM, 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
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
From: Daniel Borkmann
Date: Wed, 7 Oct 2015 10:16:09 +0200
> Similar to commit c29390c6dfee ("xps: must clear sender_cpu before
> forwarding"), we also need to clear the skb->sender_cpu when moving
> from RX to TX via skb_do_redirect() due to the shared location of
>
On Wed, Oct 7, 2015 at 8:46 AM, Alexei Starovoitov wrote:
> On 10/7/15 1:16 AM, Daniel Borkmann wrote:
>>
>> Similar to commit c29390c6dfee ("xps: must clear sender_cpu before
>> forwarding"), we also need to clear the skb->sender_cpu when moving
>> from RX to TX via
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
Similar to commit c29390c6dfee ("xps: must clear sender_cpu before
forwarding"), we also need to clear the skb->sender_cpu when moving
from RX to TX via skb_do_redirect() due to the shared location of
napi_id (used on RX) and sender_cpu (used on TX).
Fixes: 27b29f63058d ("bpf: add bpf_redirect()
On 10/7/15 1:16 AM, Daniel Borkmann wrote:
Similar to commit c29390c6dfee ("xps: must clear sender_cpu before
forwarding"), we also need to clear the skb->sender_cpu when moving
from RX to TX via skb_do_redirect() due to the shared location of
napi_id (used on RX) and sender_cpu (used on TX).
14 matches
Mail list logo