On Thu, 7 Mar 2024 18:08:24 -0800 Mina Almasry wrote:
> On Thu, Mar 7, 2024 at 5:30 PM Jakub Kicinski <kuba@xxxxxxxxxx> 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@xxxxxxxxxx/
>
> 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
