From: Simon Horman <horms@kernel.org>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org, Jakub Kicinski <kuba@kernel.org>,
Jiri Pirko <jiri@resnulli.us>,
Madhu Chittim <madhu.chittim@intel.com>,
Sridhar Samudrala <sridhar.samudrala@intel.com>,
John Fastabend <john.fastabend@gmail.com>,
Sunil Kovvuri Goutham <sgoutham@marvell.com>,
Jamal Hadi Salim <jhs@mojatatu.com>
Subject: Re: [RFC PATCH] net: introduce HW Rate Limiting Driver API
Date: Wed, 15 May 2024 15:56:44 +0100 [thread overview]
Message-ID: <20240515145644.GL154012@kernel.org> (raw)
In-Reply-To: <79767d80-4f9c-4eec-8e9d-32ea94d0e06a@lunn.ch>
On Wed, May 15, 2024 at 04:19:57PM +0200, Andrew Lunn wrote:
> > > If I read correctly, allowing each NIC to expose it's own different
> > > starting configuration still will not solve the problem for this H/W to
> > > switch from WRR to SP (and vice versa).
>
> I also suspect this is not unique to this hardware. I've not looked at
> other SOHO switches, but it is reasonably common to have different
> queues for different priority classes, and then one shaper for the
> overall port rate.
Yes, understood. It's about creating a sufficiently general solution.
And the HW you have in mind has lead us to see some shortcomings
of the proposed API in that area. Because it drew a bit too much on
understanding of a different category of HW.
> > > AFAICS, what would be needed there is an atomic set of operations:
> > > 'set_many' (and e.v. 'delete_many', 'create_many') that will allow
> > > changing all the shapers at once.
>
> Yep.
>
> > > With such operations, that H/W could still fit the expected 'no-op'
> > > default, as WRR on the queue shapers is what we expect. I agree with
> > > Jakub, handling the complexity of arbitrary starting configuration
> > > would pose a lot of trouble to the user/admin.
> > >
> > > If all the above stands together, I think we have a few options (in
> > > random order):
> > >
> > > - add both set of operations: the ones operating on a single shaper and
> > > the ones operating on multiple shapers
> > > - use only the multiple shapers ops.
> > >
> > > And the latter looks IMHO the simple/better.
>
> I would agree, start with only multiple shaper opps. If we find that
> many implementation end up just iterating the list and dealing with
> them individually, would could pull that iterator into the core, and
> expand the ops to either/or, multiple or single.
FWIIW, this was my thinking too.
> > > int (*set)(struct net_device *dev, int how_many, const u32 *handles,
> > > const struct net_shaper_info *shapers,
> > > struct netlink_ext_ack *extack);
> > > int (*reset)(struct net_device *dev, int how_many, const u32 *handles,
> > > struct netlink_ext_ack *extack);
> > > int (*move)(struct net_device *dev, int how_many, const u32 *handles,
> > > const u32 *new_parent_handles,
> > > struct netlink_ext_ack *extack);
> > >
> > > An NIC with 'static' shapers can implement a dummy move always
> > > returning EOPNOTSUPP and eventually filling a detailed extack.
>
> The extack is going to be important here, we are going to need
> meaningful error messages.
Always :)
> Overall, i think this can be made to work with the hardware i have.
Great, I think the next step is for us to propose a revised API
with multiple shaper ops in place of single shaper ops.
next prev parent reply other threads:[~2024-05-15 14:56 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-08 20:20 [RFC PATCH] net: introduce HW Rate Limiting Driver API Paolo Abeni
2024-05-08 21:47 ` Andrew Lunn
2024-05-09 14:19 ` Paolo Abeni
2024-05-09 15:00 ` Andrew Lunn
2024-05-09 15:43 ` Paolo Abeni
2024-05-09 16:17 ` Andrew Lunn
2024-05-10 11:05 ` Paolo Abeni
2024-05-15 9:51 ` Simon Horman
2024-05-15 14:19 ` Andrew Lunn
2024-05-15 14:56 ` Simon Horman [this message]
2024-05-28 17:28 ` Jakub Kicinski
2024-05-09 15:09 ` Andrew Lunn
2024-05-10 7:10 ` Naveen Mamindlapalli
2024-05-10 7:58 ` Paolo Abeni
2024-05-15 14:41 ` Andrew Lunn
2024-05-15 14:50 ` Simon Horman
2024-05-28 17:18 ` Jakub Kicinski
2024-05-31 9:22 ` Paolo Abeni
2024-05-31 16:00 ` Jakub Kicinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240515145644.GL154012@kernel.org \
--to=horms@kernel.org \
--cc=andrew@lunn.ch \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=madhu.chittim@intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sgoutham@marvell.com \
--cc=sridhar.samudrala@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).