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] [day] [month] [year] [list]

Date:   Fri, 4 Jan 2019 11:19:16 +0200
From:   Ilias Apalodimas <ilias.apalodimas@...aro.org>
To:     Po Liu <po.liu@....com>
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 Po,
> > >
> > > [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.

Well iproute2 is already used to configure an 802.1Qbv software scheduler which
is already merged into net-next [1]. 

The netdevice operations already have a callback to configure hardware 
schedulers used for CBS currently [2]. We should be able to configure the 
hardware (at least the basics) for 802.1Qbv, using those callbacks. 

Try to include switchdev maintainers in the next RFC and have a discussion on
what's the best approach to move forward on that and how to add missing
features.

I am not really sure i have all the bits and pieces correctly, but i did make a
presentation a few months ago on this [3].

Since switchdev is creating 1 ethernet interface per switch port and provides
you with a way of configuring the switch 'cpu' port individually we should be
able to fit everything in there by extending the current API's (but i might be 
missing something).

[1] Look into net/sched/sch_taprio.c for the software scheduler.
[2] .ndo_setup_tc() is the ndo callback. Look for TC_SETUP_QDISC_CBS and you'll
    get the idea. I know intel i210 and TI's cpsw driver are using it. 
[3] https://connect.linaro.org/resources/yvr18/sessions/yvr18-212/


/Ilias