netdev - Re: [PATCH net-next v2 00/10] udp_tunnel: add NIC RX port offload infrastructure

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] [day] [month] [year] [list]

Message-ID: <20200709200245.6644aa56@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Thu, 9 Jul 2020 20:02:45 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Tom Herbert <tom@...bertland.com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Saeed Mahameed <saeedm@...lanox.com>,
        Michael Chan <michael.chan@...adcom.com>,
        edwin.peer@...adcom.com, emil.s.tantilov@...el.com,
        alexander.h.duyck@...ux.intel.com,
        Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        Tariq Toukan <tariqt@...lanox.com>,
        Michal Kubecek <mkubecek@...e.cz>
Subject: Re: [PATCH net-next v2 00/10] udp_tunnel: add NIC RX port offload
 infrastructure

On Thu, 9 Jul 2020 19:33:11 -0700 Tom Herbert wrote:
> The patch set looks good for its purpose, but, sorry, I can't resist
> another round of complaining about vendors that continue to develop
> protocol specific offloads instead of moving to protocol agnostic
> generic offloads.

I agree with all your points. I hope that the improvements in visibility
into NIC capabilities and state will not encourage vendors to provide
more protocol specific offloads. 

Out-of-tree drivers for the last few generations of HW already have 
the capability to query or configure the RSS over inner fields, so 
that would just catch upstream up with the existing hacks.

I hope that building more opinionated logic as an explicit device driver
interface, rather than expecting drivers to peer directly into the state
of the stack will also help us shape the offloads. (Perhaps we would
have caught that folks are using the UDP ports for TX parsing if we
started this way.) Whether my work is misguided or I'm going about it
in a wrong way.. hard for me to tell :S

Oh, and I don't currently work for a vendor, perhaps that'd help you
trust my intentions here ;)