netdev - Re: [net-next 1/4] gve: Add basic driver framework for Compute Engine Virtual NIC

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: <20190628200628.GS27733@lunn.ch>
Date:   Fri, 28 Jun 2019 22:06:28 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     Catherine Sullivan <csully@...gle.com>, netdev@...r.kernel.org,
        Sagi Shahar <sagis@...gle.com>,
        Jon Olson <jonolson@...gle.com>,
        Willem de Bruijn <willemb@...gle.com>,
        Luigi Rizzo <lrizzo@...gle.com>
Subject: Re: [net-next 1/4] gve: Add basic driver framework for Compute
 Engine Virtual NIC

On Fri, Jun 28, 2019 at 11:46:15AM -0700, Jakub Kicinski wrote:
> On Fri, 28 Jun 2019 10:52:27 -0700, Catherine Sullivan wrote:
> > > > +if NET_VENDOR_GOOGLE
> > > > +
> > > > +config GVE
> > > > +     tristate "Google Virtual NIC (gVNIC) support"
> > > > +     depends on (PCI_MSI && X86)  
> > >
> > > We usually prefer for drivers not to depend on the platform unless
> > > really necessary, but IDK how that applies to the curious new world
> > > of NICs nobody can buy :)  
> > 
> > This is the only platform it will ever need to run on so we would really
> > prefer to not have to support others :)
> 
> I think the motivation is partially to force the uniform use of generic
> APIs across the drivers, so that re-factoring of core code is easier.
> Do you have any specific pain-points in mind where x86 dependency
> simplifies things? If not I think it's a better default to not have it.
> Not a big deal, though.

And maybe sometime in the future you might want to put this interface
in an ARM64 server?

One 'pain-paint' is that the driver might assume cache-coherency,
which is an x86 thing. If the generic APIs have been used, it should
not be an issue, but i've not spent the time to see if the DMA API has
been used correctly.

     Andrew