From: Vinicius Costa Gomes <vinicius.gomes@intel.com>
To: PO LIU <po.liu@nxp.com>,
"netdev\@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "davem\@davemloft.net" <davem@davemloft.net>,
"haustad\@cisco.com" <haustad@cisco.com>,
"nicolas.ferre\@microchip.com" <nicolas.ferre@microchip.com>,
"gregkh\@linuxfoundation.org" <gregkh@linuxfoundation.org>,
Mingkai Hu <mingkai.hu@nxp.com>, Roy Zang <roy.zang@nxp.com>,
PO LIU <po.liu@nxp.com>, PO LIU <po.liu@nxp.com>
Subject: Re: [PATCH] net: tsn: add an netlink interface between kernel and application layer
Date: Fri, 28 Dec 2018 11:29:56 -0800 [thread overview]
Message-ID: <87r2e14fgr.fsf@intel.com> (raw)
In-Reply-To: <1545968945-7290-1-git-send-email-Po.Liu@nxp.com>
Hi,
PO LIU <po.liu@nxp.com> writes:
> This patch provids netlink method to configure the TSN protocols hardwares.
> TSN guaranteed packet transport with bounded low latency, low packet delay
> variation, and low packet loss by hardware and software methods.
I don't think having another way to configure TSN features is a good
idea. We already have the CBS/ETF/taprio family of qdiscs, that provide
(or will in the near future, more on this later) a way to configure the
hardware.
A little background on the choice of qdiscs as an interface (and why we
came to believe they are a good abstraction), they already provide a way
to map packets into traffic classes (it isn't clear in our proposal how
you do that, but I think you are using something like mqprio), they
provide a neat way to "compose" (by installing one under another), they
already have a user facing API with various counters, and very
importantly for TSN they have mecanisms to offload some of their work to
the hardware.
I suggest is for you to take a look at how CBS offloading was
implemented for the Intel i210:
https://patchwork.ozlabs.org/cover/824626/
Patches 4 and 5 should be the interesting ones. I think you can use them
as inspiration for enabling CBS offload in your driver.
If you did take a look at those patches (and the current work that has
been upstreamed), my question then becomes, what are the reasons that it
might not work for your use cases?
>
> The three basic components of TSN are:
>
> 1. Time synchronization: This was implement by 8021AS which base on the
> IEEE1588 precision Time Protocol. This is configured by the other way
> in kernel.
> 8021AS not included in this patch.
>
> 2. Scheduling and traffic shaping and per-stream filter policing:
> This patch support Qbv/Qci.
I am working on a proposal for the API for Qbv (and Qbu) offloading
using taprio. I should send it soon-ish. Your feedback would be very
welcome.
Also, how to expose in the qdiscs the per-stream filtering and policing
parts (Qci) is something that I don't know how to do right now, any
suggestions would be nice.
In short, take a look at what's there and see what's missing for the
stuff that you care about, then we can work on that.
>
> 3. Selection of communication paths:
> This patch not support the pure software only TSN protocols(like Qcc)
> but hardware related configuration.
>
> TSN Protocols supports by this patch: Qbv/Qci/Qbu/Credit-base Shaper(Qav).
> This patch verified on NXP ls1028ardb board.
>
> Will add more protocols in the future.
>
> Signed-off-by: Po Liu <Po.Liu@nxp.com>
Cheers,
--
Vinicius
next prev parent reply other threads:[~2018-12-28 19:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1545968772-7237-1-git-send-email-Po.Liu@nxp.com>
2018-12-28 3:49 ` [PATCH] net: tsn: add an netlink interface between kernel and application layer PO LIU
2018-12-28 19:29 ` Vinicius Costa Gomes [this message]
2018-12-29 1:59 ` PO LIU
2019-01-02 19:01 ` Vinicius Costa Gomes
2019-01-03 3:10 ` Po Liu
2019-01-03 9:16 ` Ilias Apalodimas
2019-01-03 10:09 ` Po Liu
2019-01-03 11:38 ` Ilias Apalodimas
2019-01-04 9:01 ` Po Liu
2019-01-04 9:19 ` Ilias Apalodimas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r2e14fgr.fsf@intel.com \
--to=vinicius.gomes@intel.com \
--cc=davem@davemloft.net \
--cc=gregkh@linuxfoundation.org \
--cc=haustad@cisco.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingkai.hu@nxp.com \
--cc=netdev@vger.kernel.org \
--cc=nicolas.ferre@microchip.com \
--cc=po.liu@nxp.com \
--cc=roy.zang@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.