[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250825091622.417897ca@hermes.local>
Date: Mon, 25 Aug 2025 09:16:22 -0700
From: Stephen Hemminger <stephen@...workplumber.org>
To: Erni Sri Satya Vennela <ernis@...ux.microsoft.com>
Cc: Jakub Kicinski <kuba@...nel.org>, dsahern@...il.com,
netdev@...r.kernel.org, haiyangz@...rosoft.com,
shradhagupta@...ux.microsoft.com, ssengar@...rosoft.com,
dipayanroy@...rosoft.com, ernis@...rosoft.com
Subject: Re: [PATCH iproute2-next v3] iproute2: Add 'netshaper' command to
'ip link' for netdev shaping
On Thu, 21 Aug 2025 04:06:07 -0700
Erni Sri Satya Vennela <ernis@...ux.microsoft.com> wrote:
> On Mon, Aug 18, 2025 at 08:36:12AM -0700, Jakub Kicinski wrote:
> > On Sat, 16 Aug 2025 15:55:10 -0700 Stephen Hemminger wrote:
> > > On Mon, 11 Aug 2025 00:05:02 -0700
> > > Erni Sri Satya Vennela <ernis@...ux.microsoft.com> wrote:
> > >
> > > > Add support for the netshaper Generic Netlink
> > > > family to iproute2. Introduce a new subcommand to `ip link` for
> > > > configuring netshaper parameters directly from userspace.
> > > >
> > > > This interface allows users to set shaping attributes (such as speed)
> > > > which are passed to the kernel to perform the corresponding netshaper
> > > > operation.
> > > >
> > > > Example usage:
> > > > $ip link netshaper { set | get | delete } dev DEVNAME \
> > > > handle scope SCOPE id ID \
> > > > [ speed SPEED ]
> > >
> > > The choice of ip link is awkward and doesn't match other options.
> > > I can think of some better other choices:
> > >
> > > 1. netshaper could be a property of the device. But the choice of using genetlink
> > > instead of regular ip netlink attributes makes this hard.
> > > 2. netshaper could be part of devlink. Since it is more targeted at hardware
> > > device attributes.
> > > 3. netshaper could be a standalone command like bridge, dcb, devlink, rdma, tipc and vdpa.
> > >
> > > What ever choice the command line options need to follow similar syntax to other iproute commands.
> >
> > I think historically we gravitated towards option 3 -- each family has
> > a command? But indeed we could fold it together with something like
> > the netdev family without much issue, they are both key'd on netdevs.
> >
> > Somewhat related -- what's your take on integrating / vendoring in YNL?
> > mnl doesn't provide any extack support..
No YNL integration with iproute adds too much.
Powered by blists - more mailing lists