Hi Ilias,

-----Original Message-----
From: Ilias Apalodimas [mailto:ilias.apalodimas@linaro.org]
Sent: 2019年1月3日 19:39
To: Po Liu <redacted>
Cc: Vinicius Costa Gomes <vinicius.gomes@intel.com>; netdev@vger.kernel.org;
linux-kernel@vger.kernel.org; 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,

quoted

quoted

quoted

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.

Have you considered a switchdev-based driver for multi-port devices?

[Po] Yes, the patch is including the switchdev-based driver. In fact, we have

driver examples for  ls1028 which include end-station IP and switch ports IP,
with this interface driver, it is working. But we need to add base ethernet driver
of ENETC(end station) and FELIX(switch) upstream first, then add the TSN driver
upstream.

quoted

quoted

What you ask of TSN configuration is currently doable with switch
switchdev for VLANs and other similar networking functionality.

[Po] I think the VLAN configure is not conflict with the TSN. TSN is extending

the 8021Q. TSN configure the setting of filter frame or scheduling between TC.
But maybe need to consider as whole as you said.

VLAN was an example of devices already performing complex configuration
using switchdev and configurating 'switch' ports and 'cpu' port(s) individually.
It wasn't related to TSN or its 802.1Qbv importance in any way.

quoted

quoted

Instead of rewriting this from scratch, we not extend the currect TC
and switchdev functionality for that ?

[Po] Ya, there are operations of switchdev. You may think that to add the TSN

configurations ops into switchdev operations. But  we need to consider the end-
station devices and switch all in the devices or in the TSN domain. The TSN
domain is the devices include TSN capabilities ports, for up layer, we need to
provide a formal interface. So tsn configure can be standalone.

quoted

In this patch, we treat two kinds of ports when registering the ports, end-

station or switch. This may treat them in some minor differences in TSN spec
and drivers.

quoted

Why are switches different than end-stations configuration wise?

Minor differences but still have mentioned in spec.

I understand that you may need to support different TSN IEEE standards per
device, but adding support for different capabilities shouldn't affect a 'common'
configuration path.
That's the actual advantage of switchdev based drivers. switches and end
stations will have a very similar way of confiration via iproute2/bridge/tc utils.
Am i missing something?

I guess I start to getting your advise. Do you mean to add operations in struct switchdev_ops ? Is it proper include end station? I used to add structure tsn_ops in net_device. But I think there are some information and status of devices maintain in the kernel from drivers. So I create structure tsn_port standalone. 
Yes,  iproute2/bridge/tc is one choice for user space. I would think of the possible. But the too many parameters are still the problem. For example to create Qbv gate list.

/Ilias