From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vinicius Costa Gomes Subject: RE: [PATCH] net: tsn: add an netlink interface between kernel and application layer Date: Wed, 02 Jan 2019 11:01:41 -0800 Message-ID: <87k1jm51ey.fsf@intel.com> References: <1545968772-7237-1-git-send-email-Po.Liu@nxp.com> <1545968945-7290-1-git-send-email-Po.Liu@nxp.com> <87r2e14fgr.fsf@intel.com> Mime-Version: 1.0 Content-Type: text/plain Cc: "davem\@davemloft.net" , "haustad\@cisco.com" , "nicolas.ferre\@microchip.com" , "gregkh\@linuxfoundation.org" , Mingkai Hu , Roy Zang To: PO LIU , "netdev\@vger.kernel.org" , "linux-kernel\@vger.kernel.org" Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org Hi Po Liu, PO LIU 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