Messages in this thread | | | From | Po Liu <> | Subject | RE: [PATCH] net: tsn: add an netlink interface between kernel and application layer | Date | Fri, 4 Jan 2019 09:01:09 +0000 |
| |
Hi Ilias,
> -----Original Message----- > From: Ilias Apalodimas [mailto:ilias.apalodimas@linaro.org] > Sent: 2019年1月3日 19:39 > To: Po Liu <po.liu@nxp.com> > 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 > <mingkai.hu@nxp.com>; Roy Zang <roy.zang@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
| |