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

[Po Liu]

Hi Ilias,

> -----Original Message-----
> From: Ilias Apalodimas [mailto:ilias.apalodimas@xxxxxxxxxx]
> Sent: 2019年1月3日 19:39
> To: Po Liu <po.liu@xxxxxxx>
> Cc: Vinicius Costa Gomes <vinicius.gomes@xxxxxxxxx>; netdev@xxxxxxxxxxxxxxx;
> linux-kernel@xxxxxxxxxxxxxxx; 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,
> 
> > > > > 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?

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