Hi Po Liu,

PO LIU [off-list ref] writes:

Hi Vinicius,

Thank you very much for your feedback.

I know the CBS is used to be most important part of AVB. And qdiscs is good tool to configure qos. 

But as you know, the TSN family is a cluster of protocols and much extending the AVB. The protocols have different  functionalities and they may have more than hundred  parameters. For example NXP ls1028a support Qbv/Qci/Qbu/Qav and also the 8021CB (not included in this patch yet).

Some protocols target to configure the traffic class(like Qav CBS).
Some to config the port(like Qbv). But some for the whole ethernet
controller(like Qci, the control entries for the whole controller,
which input ports and which output ports).

Reading your email, now I understand your point a little better. You are
interested in multi-port devices. I admit that I am not too familiar
with how multi-port devices are exposed in Linux, I was only focused on
the end-station use cases, until now.

So I do think all the TSN configuration should not mix in the ethernet
driver itself. I mean the driver should separate a xxx_tsn.c(for I210,
may igb_tsn.c) to maintain the tsn operations.

As far as using qdiscs or the interface of generic netlink. I think
both could configuring the TSN protocols interface layer. Just what I
provided the patch net/tsn/genl_tsn.c. But I do believe it is better
using a standalone TSN middle layer to maintain the TSN capability
ports. Because the TSN ports include not only the end station and also
the switch. LS1028 is such a kind of device.

I think this is the "interesting" part of the discussion. From my point
of view the question now is:

"We already have an acceptable way to expoose TSN features for end
stations. What can we do for multi-port devices?"

What are the options here? From a quick look, it seems that extending
switchdev is a possible solution. What else?

Thinking a little more, if all the ports have netdevices associated with
them, then it could be that exposing those features via qdiscs could be
considered still. Perhaps taking a look at how tc-flower offloading is
done can give some ideas.

And about the process, usually when a new interface is proposed, the
patches are directed to net-next and have the RFC tag, so the readers
(and their tools) know what to expect.

And your advises are precious for us. Let's make out an easy and
flexible interface for TSN.

Br,
Po Liu

Cheers,
--
Vinicius