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

[Po Liu]

Hi Vinicius, 

Thanks!
As comments below.


Br,
Po Liu

> -----Original Message-----
> From: Vinicius Costa Gomes [mailto:vinicius.gomes@xxxxxxxxx]
> Sent: 2019年1月3日 3:02
> To: Po Liu <po.liu@xxxxxxx>; netdev@xxxxxxxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx
> Cc: davem@xxxxxxxxxxxxx; haustad@xxxxxxxxx; nicolas.ferre@xxxxxxxxxxxxx;
> gregkh@xxxxxxxxxxxxxxxxxxx; Mingkai Hu <mingkai.hu@xxxxxxx>; Roy Zang
> <roy.zang@xxxxxxx>
> Subject: RE: [PATCH] net: tsn: add an netlink interface between kernel and
> application layer
> 
> Hi Po Liu,
> 
> PO LIU <po.liu@xxxxxxx> 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?"

[Po Liu] correct, that is what we expect to do.  There could be with more than one ethernet controllers(or switch) with TSN capability. Ether pci plug in, or SOC chips. This patch try to manage all.
 
> 
> What are the options here? From a quick look, it seems that extending
> switchdev is a possible solution. What else?

[Po Liu] that's it. Could extend it.
 
> 
> 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.

[Po Liu] I did using the tc-flower at application layer to filter the frames to different queue. I avoid to using the qos but only using the multiq to make all traffic classes to be exposed to user space. I am trying to  understand what your patch working on the qdisc and how it help for TSN.

> 
> 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.

[Po Liu] thanks for the mention, I would update. 

> 
> >
> > And your advises are precious for us. Let's make out an easy and
> > flexible interface for TSN.
> >
> > Br,
> > Po Liu
> >
> 
> Cheers,
> --
> Vinicius