RE: [PATCH] net: tsn: add an netlink interface between kernel and application layer

[Vinicius Costa Gomes <vinicius.gomes@intel.com>]

Hi Po Liu,

PO LIU <po.liu@nxp.com> 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