Message-ID: <390717c3688956d6da04b7de00da3dc57ff9c7a9.camel@redhat.com>
Date: Mon, 08 Jul 2024 21:42:00 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, Jiri Pirko <jiri@...nulli.us>, Madhu Chittim
 <madhu.chittim@...el.com>, Sridhar Samudrala <sridhar.samudrala@...el.com>,
  Simon Horman <horms@...nel.org>, John Fastabend
 <john.fastabend@...il.com>, Sunil Kovvuri Goutham <sgoutham@...vell.com>,
 Jamal Hadi Salim <jhs@...atatu.com>
Subject: Re: [PATCH net-next 1/5] netlink: spec: add shaper YAML spec

On Wed, 2024-07-03 at 14:20 -0700, Jakub Kicinski wrote:
> On Wed, 03 Jul 2024 16:53:38 +0200 Paolo Abeni wrote:
> 
> > Anyway different applications must touch disjoint resources (e.g.
> > disjoint queues sets) right? In such a case even multiple destructive
> > configuration changes (on disjoint resources set) will not be
> > problematic.
> > 
> > Still if we want to allow somewhat consistent, concurrent, destructive
> > configuration changes on shared resource (why? It sounds a bit of
> > overdesign at this point), we could extend the set() operation to
> > additional support shapers deletion, e.g. adding an additional ‘delete’
> > flag attribute to the ‘handle’ sub-set.
> 
> To judge whether it's an over-design we'd need to know what the user
> scenarios are, those are not included in the series AFAICS.

My bad, in the cover I referred to the prior discussions without
explicitly quoting the contents.

The initial goal here was to allow the user-space to configure per-
queue, H/W offloaded, TX shaping.

That later evolved in introducing an in-kernel H/W offload TX shaping
API capable of replacing the many existing similar in-kernel APIs and
supporting the foreseeable H/W capabilities.

> To be blunt - what I'm getting at is that the API mirrors Intel's FW
> API with an extra kludge to support the DSA H/W - in the end matching
> neither what the DSA wants nor what Intel can do.

The API is similar to Intel’s FW API because to my understanding the
underlying design - an arbitrary tree - is the most complete
representation possible for shaping H/W. AFAICT is also similar to what
other NIC vendors’ offer.

I don’t see why the APIs don’t match what Intel can do, could you
please elaborate on that?

> IOW I'm trying to explore whether we can find a language of
> transformations which will be more complex than single micro-operations
> on the tree, but sufficiently expressive to provide atomic
> transformations without transactions of micro-ops.

I personally find it straight-forward describing the scenario you
proposed in terms of the simple operations as allowed by this series. I
also think it’s easier to build arbitrarily complex scenarios in terms
of simple operations instead of trying to put enough complexity in the
language to describe everything. It will easily lose flexibility or
increase complexity for unclear gain. Why do you think that would be a
better approach?

Also the simple building blocks approach is IMHO closer to the original
use-case.

Are there any other reasons for atomic operations, beyond addressing
low-end H/W? Note that WRT the specific limitations we are aware of,
the APIs allows atomic conf changes without resorting to transition
into the default configuration.

My biggest concern is that from my perspective we are incrementally
adding requisites, with increasing complexity, further and further away
from the initial use-case. 

Thanks,

Paolo

Powered by blists - more mailing lists