netdev - Re: [PATCH V1 net-next 0/5] Add devlink support to ena

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, 11 Jan 2023 12:00:03 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     "Arinzon, David" <darinzon@...zon.com>
Cc:     David Miller <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "Machulsky, Zorik" <zorik@...zon.com>,
        "Matushevsky, Alexander" <matua@...zon.com>,
        "Bshara, Saeed" <saeedb@...zon.com>,
        "Bshara, Nafea" <nafea@...zon.com>,
        "Saidi, Ali" <alisaidi@...zon.com>,
        "Kiyanovski, Arthur" <akiyano@...zon.com>,
        "Dagan, Noam" <ndagan@...zon.com>,
        "Agroskin, Shay" <shayagr@...zon.com>,
        "Itzko, Shahar" <itzko@...zon.com>,
        "Abboud, Osama" <osamaabb@...zon.com>
Subject: Re: [PATCH V1 net-next 0/5] Add devlink support to ena

On Wed, 11 Jan 2023 19:31:39 +0000 Arinzon, David wrote:
> If the packet network headers are not within the size of the LLQ entry, then the packet will
> be dropped. So I'll say that c) describes the impact the best given that certain types of
> traffic will not succeed or have disruptions due to dropped TX packets.

I see. Sounds like it could be a fit for
DEVLINK_ATTR_ESWITCH_INLINE_MODE ? But that one configures the depth of
the headers copied inline, rather than bytes. We could add a value for
"tunneled" and have that imply 256B LLQ in case of ena.

The other option is to introduce the concept of "max length of inline
data" to ethtool, and add a new netlink attribute to ethtool -g.

Either way - the length of "inline|push" data is not a ena-specific
concept, so using private knobs (devlink params or ethtool flags) is
not appropriate upstream. We should add a bona fide uAPI for it.