Hi Vinicius, 

Thanks!
As comments below.


Br,
Po Liu

-----Original Message-----
From: Vinicius Costa Gomes [mailto:vinicius.gomes@intel.com]
Sent: 2019年1月3日 3:02
To: Po Liu <redacted>; netdev@vger.kernel.org; linux-
kernel@vger.kernel.org
Cc: davem@davemloft.net; haustad@cisco.com; nicolas.ferre@microchip.com;
gregkh@linuxfoundation.org; Mingkai Hu [off-list ref]; Roy Zang
[off-list ref]
Subject: RE: [PATCH] net: tsn: add an netlink interface between kernel and
application layer

Hi Po Liu,

PO LIU [off-list ref] writes:

quoted

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.

quoted

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

quoted

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.

quoted

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.

quoted

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. 

quoted

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

Br,
Po Liu

Cheers,
--
Vinicius