netdev - Re: [PATCH net-next 0/5] net: busy-poll: allow preemption and other optimizations

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 16 Nov 2016 10:03:43 -0800
From:   John Fastabend <john.fastabend@...il.com>
To:     Eric Dumazet <edumazet@...gle.com>,
        "David S . Miller" <davem@...emloft.net>
Cc:     netdev <netdev@...r.kernel.org>,
        Willem de Bruijn <willemb@...gle.com>,
        Adam Belay <abelay@...gle.com>, Zach Brown <zach.brown@...com>,
        Tariq Toukan <tariqt@...lanox.com>,
        Yuval Mintz <Yuval.Mintz@...ium.com>,
        Ariel Elior <ariel.elior@...ium.com>,
        Eric Dumazet <eric.dumazet@...il.com>
Subject: Re: [PATCH net-next 0/5] net: busy-poll: allow preemption and other
 optimizations

On 16-11-15 10:15 AM, Eric Dumazet wrote:
> It is time to have preemption points in sk_busy_loop() and improve
> its scalability.
> 
> Also napi_complete() and friends can tell drivers when it is safe to
> not re-enable device interrupts, saving some overhead under
> high busy polling.
> 
> mlx4 and bnx2x are changed accordingly, to show how this busy polling
> status can be exploited by drivers.
> 
> Next steps will implement Zach Brown suggestion, where NAPI polling
> would be enabled all the time for some chosen queues.
> This is needed for efficient epoll() support anyway.

Would you expect to make this a per queue option of the hardware
configured via ethtool/netlink/sysfs and like where users steer traffic
to particular queues using existing ntuple filters or 'tc' or infer it
from the socket layer?

So configuration would be (a) enable busy-polling on queues x,y,z and
then (b) use ntuple/RSS/etc to steer relative traffic to queues. In
this case traffic doesn't need to be bound to a socket in any way.
Seems like a useful generalization.

Thanks,
John

> 
> Eric Dumazet (5):
>   net: busy-poll: allow preemption in sk_busy_loop()
>   net: busy-poll: remove need_resched() from sk_can_busy_loop()
>   net: busy-poll: return busypolling status to drivers
>   net/mlx4_en: use napi_complete_done() return value
>   bnx2x: switch to napi_complete_done()
> 
>  drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c |  15 ++--
>  drivers/net/ethernet/mellanox/mlx4/en_rx.c      |   4 +-
>  include/linux/netdevice.h                       |  17 +++-
>  include/net/busy_poll.h                         |   5 +-
>  net/core/dev.c                                  | 110 +++++++++++++++++++-----
>  5 files changed, 113 insertions(+), 38 deletions(-)
>