netdev - Re: [PATCH net-next 5/7] sfc: de-indirect TSO handling

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:   Fri, 11 Sep 2020 13:16:16 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Edward Cree <ecree@...arflare.com>
Cc:     <linux-net-drivers@...arflare.com>, <davem@...emloft.net>,
        <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 5/7] sfc: de-indirect TSO handling

On Fri, 11 Sep 2020 18:42:34 +0100 Edward Cree wrote:
> > Should tso_version 3 be handled in this switch?  
> No, because this switch is in the EF10/Siena datapath and is neverrun for
>  EF100.  Setting tx_queue->tso_version = 3 for EF100 is really just there
>  as documentation — EF100 has a completely different TX path, in
>  ef100_enqueue_skb(), which never looks at tx_queue->tso_version because
>  currently there's only one version of EF100 TSO descriptor.  From a
>  functional perspective everything would still work if it were set to 0,
>  but that would be kinda misleading.

I see, that wasn't clear from file or function names.

> Should I explain this in the commit message, or in a comment (and if the
>  latter, where should it go?)

Yeah, won't hurt.