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

[Ilias Apalodimas]

Hi Po,

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

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

Why are switches different than end-stations configuration wise?
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?

/Ilias