Hi Ilias, > -----Original Message----- > From: Ilias Apalodimas [mailto:ilias.apalodi...@linaro.org] > Sent: 2019年1月3日 19:39 > To: Po Liu <po....@nxp.com> > Cc: Vinicius Costa Gomes <vinicius.go...@intel.com>; netdev@vger.kernel.org; > linux-ker...@vger.kernel.org; da...@davemloft.net; haus...@cisco.com; > nicolas.fe...@microchip.com; gre...@linuxfoundation.org; Mingkai Hu > <mingkai...@nxp.com>; Roy Zang <roy.z...@nxp.com> > 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
