netdev - Re: pull-request: mlx5-next 2023-01-24 V2

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]

Message-ID: <20230208165234.3002ff25@kernel.org>
Date:   Wed, 8 Feb 2023 16:52:34 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Saeed Mahameed <saeed@...nel.org>
Cc:     Jason Gunthorpe <jgg@...dia.com>,
        Leon Romanovsky <leon@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Paolo Abeni <pabeni@...hat.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Saeed Mahameed <saeedm@...dia.com>, linux-rdma@...r.kernel.org,
        netdev@...r.kernel.org
Subject: Re: pull-request: mlx5-next 2023-01-24 V2

On Wed, 8 Feb 2023 16:36:18 -0800 Saeed Mahameed wrote:
>>> I honestly have no idea why you are so fixated on TC, or what it has
>>> to do with RDMA.  
>>
>> It's a strong justification for having full xfrm offload.
>> You can't forward without full offload.  
> 
> This pull has nothing to do with "full" xfrm offload, 
> For RoCE to exist it has to rely on netdev attributes, such as 
> IP, vlan, mac, etc .. in this series we do the same for ipsec,
> we setup the steering pipeline with the proper attributes for
> RoCE to function.

I think I already admitted that the exact patches in the PR are of
secondary importance.

> I don't see it will be reasonable for the rdma user to setup these
> attributes twice, once via netdev API and once via rdma APIs,
> this will be torture for that user, just because rdma bits are not allowed
> in netdev, it's exactly that, some rdma/roce bits purely mlx5_core logic,
> and it has to be in mlx5_core due to the sharing of hardware resources
> between rdma and netdev.

That's very understandable because for you as the upstream maintainer
of mlx5 either side of the equation (netdev or rdma) are "your users".
Whether we need to be concerned about their comfort is much less
obvious to netdev maintainers.