Hi Po Liu, PO LIU <po....@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
