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:50:27 +0100 [thread overview]
Message-ID: <20240515145027.GK154012@kernel.org> (raw)
In-Reply-To: <3130d582-a04c-4db5-b4a6-c02f213851be@lunn.ch>
On Wed, May 15, 2024 at 04:41:09PM +0200, Andrew Lunn wrote:
> > + * struct net_shaper_info - represents a shaping node on the NIC H/W
> > + * @metric: Specify if the bw limits refers to PPS or BPS
> > + * @bw_min: Minimum guaranteed rate for this shaper
> > + * @bw_max: Maximum peak bw allowed for this shaper
> > + * @burst: Maximum burst for the peek rate of this shaper
> > + * @priority: Scheduling priority for this shaper
> > + * @weight: Scheduling weight for this shaper
> > + */
> > +struct net_shaper_info {
> > + enum net_shaper_metric metric;
> > + u64 bw_min; /* minimum guaranteed bandwidth, according to metric */
> > + u64 bw_max; /* maximum allowed bandwidth */
> > + u32 burst; /* maximum burst in bytes for bw_max */
> > + u32 priority; /* scheduling strict priority */
> > + u32 weight; /* scheduling WRR weight*/
> > +};
>
> ...
>
> > + /** set - Update the specified shaper, if it exists
> > + * @dev: Netdevice to operate on.
> > + * @handle: the shaper identifier
> > + * @shaper: Configuration of shaper.
> > + * @extack: Netlink extended ACK for reporting errors.
> > + *
> > + * Return:
> > + * * %0 - Success
> > + * * %-EOPNOTSUPP - Operation is not supported by hardware, driver,
> > + * or core for any reason. @extack should be set to
> > + * text describing the reason.
> > + * * Other negative error values on failure.
> > + */
> > + int (*set)(struct net_device *dev, u32 handle,
> > + const struct net_shaper_info *shaper,
> > + struct netlink_ext_ack *extack);
>
> > + * net_shaper_make_handle - creates an unique shaper identifier
> > + * @scope: the shaper scope
> > + * @vf: virtual function number
> > + * @id: queue group or queue id
> > + *
> > + * Return: an unique identifier for the shaper
> > + *
> > + * Combines the specified arguments to create an unique identifier for
> > + * the shaper.
> > + * The virtual function number is only used within @NET_SHAPER_SCOPE_VF,
> > + * @NET_SHAPER_SCOPE_QUEUE_GROUP and @NET_SHAPER_SCOPE_QUEUE.
> > + * The @id number is only used for @NET_SHAPER_SCOPE_QUEUE_GROUP and
> > + * @NET_SHAPER_SCOPE_QUEUE, and must be, respectively, the queue group
> > + * identifier or the queue number.
> > + */
> > +u32 net_shaper_make_handle(enum net_shaper_scope scope, int vf, int id);
>
> One thing i'm missing here is a function which does the opposite of
> net_shaper_make_handle(). Given a handle, it returns the scope, vf and
> the id.
>
> When the set() op is called, i somehow need to find the software
> instance representing the hardware block. If i know the id, it is just
> an array access. Otherwise i need additional bookkeeping, maybe a
> linked list of handles and pointers to structures etc.
>
> Or net_shaper_make_handle() could maybe take an addition void * priv,
> and provide a function void * net_shape_priv(u32 handle);
Hi Andrew,
I think that, initially at least, the implementation of
net_shaper_make_handle() can be fairly simple, involving packing
fields into an integer in a static manner.
As such I think implementing a helper or helpers to an to extract fields
should be trivial.
In other words, yes, I think that can be added.
next prev parent reply other threads:[~2024-05-15 14:50 UTC|newest]
Thread overview: 24+ 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
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 [this message]
2024-05-28 17:18 ` Jakub Kicinski
2024-05-31 9:22 ` Paolo Abeni
2024-05-31 16:00 ` Jakub Kicinski
2024-06-03 11:11 ` Paolo Abeni
2024-06-03 23:29 ` Jakub Kicinski
2024-06-05 15:04 ` Cosmin Ratiu
2024-06-05 15:52 ` Paolo Abeni
2024-06-05 19:40 ` 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=20240515145027.GK154012@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).