From: Jakub Kicinski <kuba@kernel.org>
To: Paolo Abeni <pabeni@redhat.com>
Cc: netdev@vger.kernel.org, Jiri Pirko <jiri@resnulli.us>,
Madhu Chittim <madhu.chittim@intel.com>,
Sridhar Samudrala <sridhar.samudrala@intel.com>,
Simon Horman <horms@kernel.org>,
John Fastabend <john.fastabend@gmail.com>,
Sunil Kovvuri Goutham <sgoutham@marvell.com>,
Jamal Hadi Salim <jhs@mojatatu.com>
Subject: Re: [PATCH net-next 1/5] netlink: spec: add shaper YAML spec
Date: Tue, 2 Jul 2024 08:04:52 -0700 [thread overview]
Message-ID: <20240702080452.06e363ae@kernel.org> (raw)
In-Reply-To: <e683f849274f95ce99607e79cba21111997454f9.camel@redhat.com>
On Tue, 02 Jul 2024 16:21:38 +0200 Paolo Abeni wrote:
> > I see, I had a look at patch 2 now.
> > But that's really "Andrew's use-case" it doesn't cover deletion, right?
> > Sorry that I don't have a perfect suggestion either but it seems like
> > a half-measure. It's a partial support for transactions. If we want
> > transactions we should group ops like nftables. Have normal ops (add,
> > delete, modify) and control ops (start, commit) which clone the entire
> > tree, then ops change it, and commit presents new tree to the device.
>
> Yes, it does not cover deletion _and_ update/add/move within the same
> atomic operation.
>
> Still any configuration could be reached from default/initial state
> with set(<possibly many shapers>). Additionally, given any arbitrary
> configuration, the default/initial state could be restored with a
> single delete(<possibly many handlers>).
From:
q0 -. RR \
q1 / > SP
q2 -. RR /
q3 /
To:
q0 ------\
q1 -------> SP
q2 -. RR /
q3 /
You have to both delete an RR node, and set SP params on Q0 and Q1.
> The above covers any possible limitation enforced by the H/W, not just
> the DSA use-case.
>
> Do you have a strong feeling for atomic transactions from any arbitrary
> state towards any other? If so, I’d like to understand why?
I don't believe this is covers all cases.
> Dealing with transactions allowing arbitrary any state <> any state
> atomic changes will involve some complex logic that seems better
> assigned to user-space.
Complex logic in which part of the code?
It's just a full clone of the xarray, then do whatever ops user is
asking to do, then tree walk to render diff as a set of ops.
If you mean the tree walk to convert tree diff into ops, I think we
need that anyway, otherwise we may get into a situation where there's
a dependency between the user space implementation and driver
expectations.
next prev parent reply other threads:[~2024-07-02 15:04 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-27 20:17 [PATCH net-next 0/5] net: introduce TX shaping H/W offload API Paolo Abeni
2024-06-27 20:17 ` [PATCH net-next 1/5] netlink: spec: add shaper YAML spec Paolo Abeni
2024-06-29 2:12 ` Jakub Kicinski
2024-07-01 10:14 ` Paolo Abeni
2024-07-02 2:54 ` Jakub Kicinski
2024-07-02 14:21 ` Paolo Abeni
2024-07-02 15:04 ` Jakub Kicinski [this message]
[not found] ` <CAF6piCLnrDWo70ZgXLtdmRkr+w5TMtuXPMW9=JKSSN2fvw1HMA@mail.gmail.com>
2024-07-02 19:51 ` Fwd: " Paolo Abeni
[not found] ` <20240702140830.2890f77b@kernel.org>
2024-07-03 14:53 ` Paolo Abeni
2024-07-03 21:20 ` Jakub Kicinski
2024-07-08 19:42 ` Paolo Abeni
2024-07-09 2:54 ` Jakub Kicinski
2024-07-01 14:50 ` Paolo Abeni
2024-07-01 15:50 ` Paolo Abeni
2024-07-02 0:37 ` Jakub Kicinski
2024-06-27 20:17 ` [PATCH net-next 2/5] net: introduce HW Rate limiting driver API Paolo Abeni
2024-06-27 20:17 ` [PATCH net-next 3/5] netlink: spec: add shaper introspection support Paolo Abeni
2024-06-27 20:17 ` [PATCH net-next 4/5] net: shaper: implement " Paolo Abeni
2024-06-27 20:17 ` [PATCH net-next 5/5] testing: net-drv: add basic shaper test Paolo Abeni
2024-06-29 2:03 ` [PATCH net-next 0/5] net: introduce TX shaping H/W offload API 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=20240702080452.06e363ae@kernel.org \
--to=kuba@kernel.org \
--cc=horms@kernel.org \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=john.fastabend@gmail.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.