From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"jhs@mojatatu.com" <jhs@mojatatu.com>,
"xiyou.wangcong@gmail.com" <xiyou.wangcong@gmail.com>,
"jiri@resnulli.us" <jiri@resnulli.us>,
"m-karicheri2@ti.com" <m-karicheri2@ti.com>,
"Jose.Abreu@synopsys.com" <Jose.Abreu@synopsys.com>,
Po Liu <po.liu@nxp.com>,
"intel-wired-lan@lists.osuosl.org"
<intel-wired-lan@lists.osuosl.org>,
"anthony.l.nguyen@intel.com" <anthony.l.nguyen@intel.com>
Subject: Re: [PATCH net-next v1 0/9] ethtool: Add support for frame preemption
Date: Mon, 7 Dec 2020 23:12:31 +0000 [thread overview]
Message-ID: <20201207231230.3avhe6yqklsbxsiz@skbuf> (raw)
In-Reply-To: <87o8j5z0xs.fsf@intel.com>
On Mon, Dec 07, 2020 at 02:49:35PM -0800, Vinicius Costa Gomes wrote:
> Jakub Kicinski <kuba@kernel.org> writes:
>
> > On Tue, 1 Dec 2020 20:53:16 -0800 Vinicius Costa Gomes wrote:
> >> $ tc qdisc replace dev $IFACE parent root handle 100 taprio \
> >> num_tc 3 \
> >> map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 \
> >> queues 1@0 1@1 2@2 \
> >> base-time $BASE_TIME \
> >> sched-entry S 0f 10000000 \
> >> preempt 1110 \
> >> flags 0x2
> >>
> >> The "preempt" parameter is the only difference, it configures which
> >> queues are marked as preemptible, in this example, queue 0 is marked
> >> as "not preemptible", so it is express, the rest of the four queues
> >> are preemptible.
> >
> > Does it make more sense for the individual queues to be preemptible
> > or not, or is it better controlled at traffic class level?
> > I was looking at patch 2, and 32 queues isn't that many these days..
> > We either need a larger type there or configure this based on classes.
>
> I can set more future proof sizes for expressing the queues, sure, but
> the issue, I think, is that frame preemption has dimishing returns with
> link speed: at 2.5G the latency improvements are on the order of single
> digit microseconds. At greater speeds the improvements are even less
> noticeable.
You could look at it another way.
You can enable jumbo frames in your network, and your latency-sensitive
traffic would not suffer as long as the jumbo frames are preemptible.
> The only adapters that I see that support frame preemtion have 8 queues
> or less.
>
> The idea of configuring frame preemption based on classes is
> interesting. I will play with it, and see how it looks.
I admit I never understood why you insist on configuring TSN offloads
per hardware queue and not per traffic class.
WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [PATCH net-next v1 0/9] ethtool: Add support for frame preemption
Date: Mon, 7 Dec 2020 23:12:31 +0000 [thread overview]
Message-ID: <20201207231230.3avhe6yqklsbxsiz@skbuf> (raw)
In-Reply-To: <87o8j5z0xs.fsf@intel.com>
On Mon, Dec 07, 2020 at 02:49:35PM -0800, Vinicius Costa Gomes wrote:
> Jakub Kicinski <kuba@kernel.org> writes:
>
> > On Tue, 1 Dec 2020 20:53:16 -0800 Vinicius Costa Gomes wrote:
> >> $ tc qdisc replace dev $IFACE parent root handle 100 taprio \
> >> num_tc 3 \
> >> map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 \
> >> queues 1 at 0 1 at 1 2 at 2 \
> >> base-time $BASE_TIME \
> >> sched-entry S 0f 10000000 \
> >> preempt 1110 \
> >> flags 0x2
> >>
> >> The "preempt" parameter is the only difference, it configures which
> >> queues are marked as preemptible, in this example, queue 0 is marked
> >> as "not preemptible", so it is express, the rest of the four queues
> >> are preemptible.
> >
> > Does it make more sense for the individual queues to be preemptible
> > or not, or is it better controlled at traffic class level?
> > I was looking at patch 2, and 32 queues isn't that many these days..
> > We either need a larger type there or configure this based on classes.
>
> I can set more future proof sizes for expressing the queues, sure, but
> the issue, I think, is that frame preemption has dimishing returns with
> link speed: at 2.5G the latency improvements are on the order of single
> digit microseconds. At greater speeds the improvements are even less
> noticeable.
You could look at it another way.
You can enable jumbo frames in your network, and your latency-sensitive
traffic would not suffer as long as the jumbo frames are preemptible.
> The only adapters that I see that support frame preemtion have 8 queues
> or less.
>
> The idea of configuring frame preemption based on classes is
> interesting. I will play with it, and see how it looks.
I admit I never understood why you insist on configuring TSN offloads
per hardware queue and not per traffic class.
next prev parent reply other threads:[~2020-12-07 23:13 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-02 4:53 [PATCH net-next v1 0/9] ethtool: Add support for frame preemption Vinicius Costa Gomes
2020-12-02 4:53 ` [Intel-wired-lan] " Vinicius Costa Gomes
2020-12-02 4:53 ` [PATCH net-next v1 1/9] ethtool: Add support for configuring " Vinicius Costa Gomes
2020-12-02 4:53 ` [Intel-wired-lan] " Vinicius Costa Gomes
2020-12-03 1:53 ` Jakub Kicinski
2020-12-03 1:53 ` [Intel-wired-lan] " Jakub Kicinski
2020-12-05 17:43 ` Jakub Kicinski
2020-12-05 17:43 ` [Intel-wired-lan] " Jakub Kicinski
2020-12-07 22:11 ` Vinicius Costa Gomes
2020-12-07 22:11 ` [Intel-wired-lan] " Vinicius Costa Gomes
2020-12-07 23:21 ` Jakub Kicinski
2020-12-07 23:21 ` [Intel-wired-lan] " Jakub Kicinski
2020-12-08 0:24 ` Vinicius Costa Gomes
2020-12-08 0:24 ` [Intel-wired-lan] " Vinicius Costa Gomes
2020-12-08 0:27 ` Vladimir Oltean
2020-12-08 0:27 ` [Intel-wired-lan] " Vladimir Oltean
2020-12-08 0:48 ` Jakub Kicinski
2020-12-08 0:48 ` [Intel-wired-lan] " Jakub Kicinski
2020-12-08 6:22 ` Michal Kubecek
2020-12-08 6:22 ` [Intel-wired-lan] " Michal Kubecek
2020-12-02 4:53 ` [PATCH net-next v1 2/9] taprio: Add support for frame preemption offload Vinicius Costa Gomes
2020-12-02 4:53 ` [Intel-wired-lan] " Vinicius Costa Gomes
2020-12-02 4:53 ` [PATCH net-next v1 3/9] igc: Set the RX packet buffer size for TSN mode Vinicius Costa Gomes
2020-12-02 4:53 ` [Intel-wired-lan] " Vinicius Costa Gomes
2020-12-02 4:53 ` [PATCH net-next v1 4/9] igc: Only dump registers if configured to dump HW information Vinicius Costa Gomes
2020-12-02 4:53 ` [Intel-wired-lan] " Vinicius Costa Gomes
2020-12-02 4:53 ` [PATCH net-next v1 5/9] igc: Avoid TX Hangs because long cycles Vinicius Costa Gomes
2020-12-02 4:53 ` [Intel-wired-lan] " Vinicius Costa Gomes
2020-12-02 4:53 ` [PATCH net-next v1 6/9] igc: Add support for tuning frame preemption via ethtool Vinicius Costa Gomes
2020-12-02 4:53 ` [Intel-wired-lan] " Vinicius Costa Gomes
2020-12-05 18:00 ` Jakub Kicinski
2020-12-05 18:00 ` [Intel-wired-lan] " Jakub Kicinski
2020-12-07 22:15 ` Vinicius Costa Gomes
2020-12-07 22:15 ` [Intel-wired-lan] " Vinicius Costa Gomes
2020-12-07 23:22 ` Jakub Kicinski
2020-12-07 23:22 ` [Intel-wired-lan] " Jakub Kicinski
2020-12-02 4:53 ` [PATCH net-next v1 7/9] igc: Add support for Frame Preemption offload Vinicius Costa Gomes
2020-12-02 4:53 ` [Intel-wired-lan] " Vinicius Costa Gomes
2020-12-02 4:53 ` [PATCH net-next v1 8/9] igc: Add support for exposing frame preemption stats registers Vinicius Costa Gomes
2020-12-02 4:53 ` [Intel-wired-lan] " Vinicius Costa Gomes
2020-12-05 17:59 ` Jakub Kicinski
2020-12-05 17:59 ` [Intel-wired-lan] " Jakub Kicinski
2020-12-07 22:29 ` Vinicius Costa Gomes
2020-12-07 22:29 ` [Intel-wired-lan] " Vinicius Costa Gomes
2020-12-02 4:53 ` [PATCH net-next v1 9/9] igc: Separate TSN configurations that can be updated Vinicius Costa Gomes
2020-12-02 4:53 ` [Intel-wired-lan] " Vinicius Costa Gomes
2020-12-05 17:50 ` [PATCH net-next v1 0/9] ethtool: Add support for frame preemption Jakub Kicinski
2020-12-05 17:50 ` [Intel-wired-lan] " Jakub Kicinski
2020-12-07 22:49 ` Vinicius Costa Gomes
2020-12-07 22:49 ` [Intel-wired-lan] " Vinicius Costa Gomes
2020-12-07 23:12 ` Vladimir Oltean [this message]
2020-12-07 23:12 ` Vladimir Oltean
2020-12-08 0:34 ` Vinicius Costa Gomes
2020-12-08 0:34 ` [Intel-wired-lan] " Vinicius Costa Gomes
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=20201207231230.3avhe6yqklsbxsiz@skbuf \
--to=vladimir.oltean@nxp.com \
--cc=Jose.Abreu@synopsys.com \
--cc=anthony.l.nguyen@intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=m-karicheri2@ti.com \
--cc=netdev@vger.kernel.org \
--cc=po.liu@nxp.com \
--cc=vinicius.gomes@intel.com \
--cc=xiyou.wangcong@gmail.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.