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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <VI1PR04MB51357307440F6B89831741F5928E0@VI1PR04MB5135.eurprd04.prod.outlook.com>
Date:   Fri, 4 Jan 2019 09:01:09 +0000
From:   Po Liu <po.liu@....com>
To:     Ilias Apalodimas <ilias.apalodimas@...aro.org>
CC:     Vinicius Costa Gomes <vinicius.gomes@...el.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "haustad@...co.com" <haustad@...co.com>,
        "nicolas.ferre@...rochip.com" <nicolas.ferre@...rochip.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        Mingkai Hu <mingkai.hu@....com>, Roy Zang <roy.zang@....com>
Subject: RE: [PATCH] net: tsn: add an netlink interface between kernel and
 application layer

Hi Ilias,

> -----Original Message-----
> From: Ilias Apalodimas [mailto:ilias.apalodimas@...aro.org]
> Sent: 2019年1月3日 19:39
> To: Po Liu <po.liu@....com>
> Cc: Vinicius Costa Gomes <vinicius.gomes@...el.com>; netdev@...r.kernel.org;
> linux-kernel@...r.kernel.org; davem@...emloft.net; haustad@...co.com;
> nicolas.ferre@...rochip.com; gregkh@...uxfoundation.org; Mingkai Hu
> <mingkai.hu@....com>; Roy Zang <roy.zang@....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