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: <87k1jm51ey.fsf@intel.com>
Date:   Wed, 02 Jan 2019 11:01:41 -0800
From:   Vinicius Costa Gomes <vinicius.gomes@...el.com>
To:     PO LIU <po.liu@....com>,
        "netdev\@vger.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>
Cc:     "davem\@davemloft.net" <davem@...emloft.net>,
        "haustad\@cisco.com" <haustad@...co.com>,
        "nicolas.ferre\@microchip.com" <nicolas.ferre@...rochip.com>,
        "gregkh\@linuxfoundation.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 Liu,

PO LIU <po.liu@....com> writes:

> Hi Vinicius,
>
> Thank you very much for your feedback.
>
> I know the CBS is used to be most important part of AVB. And qdiscs is good tool to configure qos. 
>
> But as you know, the TSN family is a cluster of protocols and much extending the AVB. The protocols have different  functionalities and they may have more than hundred  parameters. For example NXP ls1028a support Qbv/Qci/Qbu/Qav and also the 8021CB (not included in this patch yet).
>
> 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.

>
> So I do think all the TSN configuration should not mix in the ethernet
> driver itself. I mean the driver should separate a xxx_tsn.c(for I210,
> may igb_tsn.c) to maintain the tsn operations.

> As far as using qdiscs or the interface of generic netlink. I think
> both could configuring the TSN protocols interface layer. Just what I
> provided the patch net/tsn/genl_tsn.c. But I do believe it is better
> using a standalone TSN middle layer to maintain the TSN capability
> ports. Because the TSN ports include not only the end station and also
> the switch. LS1028 is such a kind of device.

I think this is the "interesting" part of the discussion. From my point
of view the question now is:

"We already have an acceptable way to expoose TSN features for end
stations. What can we do for multi-port devices?"

What are the options here? From a quick look, it seems that extending
switchdev is a possible solution. What else?

Thinking a little more, if all the ports have netdevices associated with
them, then it could be that exposing those features via qdiscs could be
considered still. Perhaps taking a look at how tc-flower offloading is
done can give some ideas.

And about the process, usually when a new interface is proposed, the
patches are directed to net-next and have the RFC tag, so the readers
(and their tools) know what to expect.

>
> And your advises are precious for us. Let's make out an easy and
> flexible interface for TSN.
>
> Br,
> Po Liu
>

Cheers,
--
Vinicius