netdev - Re: [PATCH] octeontx2-nicvf: Add netdev interface support for SDP VF devices

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]

Date:   Fri, 26 Nov 2021 09:19:27 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Sunil Kovvuri <sunil.kovvuri@...il.com>
Cc:     Linux Netdev List <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Sunil Goutham <sgoutham@...vell.com>
Subject: Re: [PATCH] octeontx2-nicvf: Add netdev interface support for SDP
 VF devices

On Fri, 26 Nov 2021 10:51:24 +0530 Sunil Kovvuri wrote:
> On Fri, Nov 26, 2021 at 10:28 AM Jakub Kicinski <kuba@...nel.org> wrote:
> > On Fri, 26 Nov 2021 09:44:10 +0530 Sunil Kovvuri wrote:  
> > > What is the objection here ?
> > > Is kernel netdev not supposed to be used with-in end-point ?  
> >
> > Yes.  
> 
> If you don't mind can you please write these rules somewhere and push
> to kernel documentation.
> So that we are clear on what restrictions kernel netdev imposes.

Kernel develops by precedent. You're making a precedent with your
patches and have not bothered documenting it. In fact there isn't 
even a proper commit message.

> > > If customers want to use upstream kernel with-in endpoint and not
> > > proprietary SDK, why to impose restrictions.  
> >
> > Because our APIs and interfaces have associated semantics. That's
> > the primary thing we care about upstream. You need to use or create
> > standard interfaces, not come up with your own thing and retrofit it
> > into one of the APIs. Not jam PTP configuration thru devlink params,
> > or use netdevs to talk to your FW because its convenient. Trust me,
> > you're not the first one to come up with this idea.
> 
> I see that you are just assuming how it's used and making comments.
> In scenarios where OcteonTx2 is used as a offload card (DPU) or VRAN,
> some of the pkts
> will be sent to host for processing. This path is used to forward such
> pkts to host and viceversa.
> It's not for internal communication between host and firmware.

Sounds like you should be implementing the switchdev model, then.

> It's using the standard netdev interfaces, APIs and network stack
> packet forwarding.
> I don't understand what's wrong with this.

Again, upstream comes with expectations around semantics of objects 
and modeling.

> The devlink params are being used across drivers to do proprietary
> HW settings. There is no PTP protocol or pkt related configuration
> that's being jammed through in the other patch.

I don't even know how to respond to this. And guess what, PTP is
relatively well documented, which clearly proves that your "please
document.." request is empty rhetoric.

> > Frankly if the octeontx2 team continues on its current path I think
> > the driver should be removed. You bring no benefit to the community
> > I don't see why we'd give you the time of day.  
> 
> That's an unnecessary comment crossing the lines.

I'm not sure why. Please elucidate how working with your team is
bringing any benefit to the community.