netdev - Re: [RFC PATCH net-next v6 01/15] queue

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: <20240307193646.70ef5243@kernel.org>
Date: Thu, 7 Mar 2024 19:36:46 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Mina Almasry <almasrymina@...gle.com>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-doc@...r.kernel.org, linux-alpha@...r.kernel.org,
 linux-mips@...r.kernel.org, linux-parisc@...r.kernel.org,
 sparclinux@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
 linux-arch@...r.kernel.org, bpf@...r.kernel.org,
 linux-kselftest@...r.kernel.org, linux-media@...r.kernel.org,
 dri-devel@...ts.freedesktop.org, "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
 Jonathan Corbet <corbet@....net>, Richard Henderson
 <richard.henderson@...aro.org>, Ivan Kokshaysky <ink@...assic.park.msu.ru>,
 Matt Turner <mattst88@...il.com>, Thomas Bogendoerfer
 <tsbogend@...ha.franken.de>, "James E.J. Bottomley"
 <James.Bottomley@...senpartnership.com>, Helge Deller <deller@....de>,
 Andreas Larsson <andreas@...sler.com>, Jesper Dangaard Brouer
 <hawk@...nel.org>, Ilias Apalodimas <ilias.apalodimas@...aro.org>, Steven
 Rostedt <rostedt@...dmis.org>, Masami Hiramatsu <mhiramat@...nel.org>,
 Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Arnd Bergmann
 <arnd@...db.de>, Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann
 <daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>, Martin KaFai
 Lau <martin.lau@...ux.dev>, Eduard Zingerman <eddyz87@...il.com>, Song Liu
 <song@...nel.org>, Yonghong Song <yonghong.song@...ux.dev>, John Fastabend
 <john.fastabend@...il.com>, KP Singh <kpsingh@...nel.org>, Stanislav
 Fomichev <sdf@...gle.com>, Hao Luo <haoluo@...gle.com>, Jiri Olsa
 <jolsa@...nel.org>, David Ahern <dsahern@...nel.org>, Willem de Bruijn
 <willemdebruijn.kernel@...il.com>, Shuah Khan <shuah@...nel.org>, Sumit
 Semwal <sumit.semwal@...aro.org>, Christian König
 <christian.koenig@....com>, Pavel Begunkov <asml.silence@...il.com>, David
 Wei <dw@...idwei.uk>, Jason Gunthorpe <jgg@...pe.ca>, Yunsheng Lin
 <linyunsheng@...wei.com>, Shailend Chand <shailend@...gle.com>, Harshitha
 Ramamurthy <hramamurthy@...gle.com>, Shakeel Butt <shakeelb@...gle.com>,
 Jeroen de Borst <jeroendb@...gle.com>, Praveen Kaligineedi
 <pkaligineedi@...gle.com>
Subject: Re: [RFC PATCH net-next v6 01/15] queue_api: define queue api

On Thu, 7 Mar 2024 18:08:24 -0800 Mina Almasry wrote:
> On Thu, Mar 7, 2024 at 5:30 PM Jakub Kicinski <kuba@...nel.org> wrote:
> > On Mon,  4 Mar 2024 18:01:36 -0800 Mina Almasry wrote:  
> > > + * void *(*ndo_queue_mem_alloc)(struct net_device *dev, int idx);
> > > + *   Allocate memory for an RX queue. The memory returned in the form of
> > > + *   a void * can be passed to ndo_queue_mem_free() for freeing or to
> > > + *   ndo_queue_start to create an RX queue with this memory.
> > > + *
> > > + * void      (*ndo_queue_mem_free)(struct net_device *dev, void *);
> > > + *   Free memory from an RX queue.
> > > + *
> > > + * int (*ndo_queue_start)(struct net_device *dev, int idx, void *);
> > > + *   Start an RX queue at the specified index.
> > > + *
> > > + * int (*ndo_queue_stop)(struct net_device *dev, int idx, void **);
> > > + *   Stop the RX queue at the specified index.
> > >   */
> > >  struct net_device_ops {
> > >       int                     (*ndo_init)(struct net_device *dev);
> > > @@ -1679,6 +1693,16 @@ struct net_device_ops {
> > >       int                     (*ndo_hwtstamp_set)(struct net_device *dev,
> > >                                                   struct kernel_hwtstamp_config *kernel_config,
> > >                                                   struct netlink_ext_ack *extack);
> > > +     void *                  (*ndo_queue_mem_alloc)(struct net_device *dev,
> > > +                                                    int idx);
> > > +     void                    (*ndo_queue_mem_free)(struct net_device *dev,
> > > +                                                   void *queue_mem);
> > > +     int                     (*ndo_queue_start)(struct net_device *dev,
> > > +                                                int idx,
> > > +                                                void *queue_mem);
> > > +     int                     (*ndo_queue_stop)(struct net_device *dev,
> > > +                                               int idx,
> > > +                                               void **out_queue_mem);  
> >
> > The queue configuration object was quite an integral part of the design,
> > I'm slightly worried that it's not here :)  
> 
> That was a bit of a simplification I'm making since we just want to
> restart the queue. I thought it was OK to define some minimal version
> here and extend it later with configuration? Because in this context
> all we really need is to restart the queue, yes?

Right, I think it's perfectly fine for the time being.
It works, and is internal to the kernel.

> If extending with some configuration is a must please let me know what
> configuration struct you're envisioning. Were you envisioning a stub?
> Or some real configuration struct that we just don't use at the
> moment? Or one that we use for this use case somehow?

I had some ideas about storing the configuration as rules,
instead of directly in struct netdev_rx_queue.
E.g. default queue length = 2000, but for select queues you may
want a different length.
But application binding to a queue would always take precedence, 
so even if the ideas ever materialize there will be no uAPI change.

> > Also we may want to rename
> > the about-to-be-merged ops from netdev_stat_ops and netdev_queue_ops,
> > and add these there?
> >
> > https://lore.kernel.org/all/20240306195509.1502746-2-kuba@kernel.org/
> 
> Yeah, that sounds reasonable! Thanks! We could also keep the
> netdev_stat_ops and add new netdev_queue_ops alongside them if you
> prefer.

Up to you, after some soul searching we renamed the uAPI to call these
stats qstats, I just forgot to rename the op struct. But it doesn't
matter much.

> > Very excited to hear that you made progress on this and ported GVE over!  
> 
> Actually, we're still discussing but it looks like my GVE queue API
> implementation I proposed earlier may be a no-go. Likely someone from
> the GVE team will follow up here with this piece, probably in a
> separate series.

Well, it's going to be ready when it's ready :)
Speaking of things which can be merged independently,
feel free to post patch 3, maybe it can make v6.9..

> For now I'm carrying my POC for the GVE implementation out of tree
> with the rest of the driver changes:
> 
> https://github.com/mina/linux/commit/501b734c80186545281e9edb1bf313f5a2d8cbee