All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: David Miller <davem@davemloft.net>
Cc: Vinicius Costa Gomes <vinicius.gomes@intel.com>,
	intel-wired-lan@lists.osuosl.org,
	Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
	netdev <netdev@vger.kernel.org>,
	Vladimir Oltean <vladimir.oltean@nxp.com>,
	Po Liu <po.liu@nxp.com>, Murali Karicheri <m-karicheri2@ti.com>,
	Jose Abreu <Jose.Abreu@synopsys.com>
Subject: Re: [next-queue RFC 0/4] ethtool: Add support for frame preemption
Date: Sun, 17 May 2020 13:51:19 +0300	[thread overview]
Message-ID: <CA+h21hrg_CeD2-zT+7v3b3hPRFaeggmZC9NqPp+soedCYwG63A@mail.gmail.com> (raw)
In-Reply-To: <20200516.151932.575795129235955389.davem@davemloft.net>

On Sun, 17 May 2020 at 01:19, David Miller <davem@davemloft.net> wrote:
>
> From: Vladimir Oltean <olteanv@gmail.com>
> Date: Sun, 17 May 2020 00:03:39 +0300
>
> > As to why this doesn't go to tc but to ethtool: why would it go to tc?
>
> Maybe you can't %100 duplicate the on-the-wire special format and
> whatever, but the queueing behavior ABSOLUTELY you can emulate in
> software.
>
> And then you have the proper hooks added for HW offload which can
> do the on-the-wire stuff.
>
> That's how we do these things, not with bolted on ethtool stuff.

When talking about frame preemption in the way that it is defined in
802.1Qbu and 802.3br, it says or assumes nothing about queuing. It
describes the fact that there are 2 MACs per interface, 1 MAC dealing
with some traffic classes and the other dealing with the rest. Queuing
sits completely above the layer where frame preemption happens:
- The queuing layer does not care if packets go to a traffic class
that is serviced by a preemptible MAC or an express MAC
- The MAC does not care by what means have packets been classified to
one traffic class or another.
I have no idea what emulation of queuing behavior you are talking
about. Frame preemption is a MAC hardware feature. Your NIC supports
it or it doesn't. Which means it can talk to a link partner that
supports frame preemption, or it can't.

Thanks,
-Vladimir

WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Oltean <olteanv@gmail.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [next-queue RFC 0/4] ethtool: Add support for frame preemption
Date: Sun, 17 May 2020 13:51:19 +0300	[thread overview]
Message-ID: <CA+h21hrg_CeD2-zT+7v3b3hPRFaeggmZC9NqPp+soedCYwG63A@mail.gmail.com> (raw)
In-Reply-To: <20200516.151932.575795129235955389.davem@davemloft.net>

On Sun, 17 May 2020 at 01:19, David Miller <davem@davemloft.net> wrote:
>
> From: Vladimir Oltean <olteanv@gmail.com>
> Date: Sun, 17 May 2020 00:03:39 +0300
>
> > As to why this doesn't go to tc but to ethtool: why would it go to tc?
>
> Maybe you can't %100 duplicate the on-the-wire special format and
> whatever, but the queueing behavior ABSOLUTELY you can emulate in
> software.
>
> And then you have the proper hooks added for HW offload which can
> do the on-the-wire stuff.
>
> That's how we do these things, not with bolted on ethtool stuff.

When talking about frame preemption in the way that it is defined in
802.1Qbu and 802.3br, it says or assumes nothing about queuing. It
describes the fact that there are 2 MACs per interface, 1 MAC dealing
with some traffic classes and the other dealing with the rest. Queuing
sits completely above the layer where frame preemption happens:
- The queuing layer does not care if packets go to a traffic class
that is serviced by a preemptible MAC or an express MAC
- The MAC does not care by what means have packets been classified to
one traffic class or another.
I have no idea what emulation of queuing behavior you are talking
about. Frame preemption is a MAC hardware feature. Your NIC supports
it or it doesn't. Which means it can talk to a link partner that
supports frame preemption, or it can't.

Thanks,
-Vladimir

  reply	other threads:[~2020-05-17 10:51 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-16  1:29 [next-queue RFC 0/4] ethtool: Add support for frame preemption Vinicius Costa Gomes
2020-05-16  1:29 ` [Intel-wired-lan] " Vinicius Costa Gomes
2020-05-16  1:29 ` [next-queue RFC 1/4] ethtool: Add support for configuring " Vinicius Costa Gomes
2020-05-16  1:29   ` [Intel-wired-lan] " Vinicius Costa Gomes
2020-05-19 15:27   ` Murali Karicheri
2020-05-19 15:27     ` [Intel-wired-lan] " Murali Karicheri
2020-05-16  1:29 ` [next-queue RFC 2/4] ethtool: Add support for configuring frame preemption via netlink Vinicius Costa Gomes
2020-05-16  1:29   ` [Intel-wired-lan] " Vinicius Costa Gomes
2020-05-18 12:27   ` Dan Carpenter
2020-05-18 12:27     ` Dan Carpenter
2020-05-16  1:29 ` [next-queue RFC 3/4] igc: Add support for configuring frame preemption Vinicius Costa Gomes
2020-05-16  1:29   ` [Intel-wired-lan] " Vinicius Costa Gomes
2020-05-19 16:36   ` Murali Karicheri
2020-05-19 16:36     ` [Intel-wired-lan] " Murali Karicheri
2020-05-16  1:29 ` [next-queue RFC 4/4] igc: Add support for exposing frame preemption stats registers Vinicius Costa Gomes
2020-05-16  1:29   ` [Intel-wired-lan] " Vinicius Costa Gomes
2020-05-20 12:50   ` Murali Karicheri
2020-05-20 12:50     ` [Intel-wired-lan] " Murali Karicheri
2020-05-16  9:33 ` [next-queue RFC 0/4] ethtool: Add support for frame preemption Michal Kubecek
2020-05-16  9:33   ` [Intel-wired-lan] " Michal Kubecek
2020-05-18 19:34   ` Vinicius Costa Gomes
2020-05-18 19:34     ` [Intel-wired-lan] " Vinicius Costa Gomes
2020-05-19 22:40     ` Andre Guedes
2020-05-19 22:40       ` [Intel-wired-lan] " Andre Guedes
2020-05-19 22:53       ` Vinicius Costa Gomes
2020-05-19 22:53         ` [Intel-wired-lan] " Vinicius Costa Gomes
2020-05-16 20:37 ` David Miller
2020-05-16 20:37   ` [Intel-wired-lan] " David Miller
2020-05-16 21:03   ` Vladimir Oltean
2020-05-16 21:03     ` [Intel-wired-lan] " Vladimir Oltean
2020-05-16 22:19     ` David Miller
2020-05-16 22:19       ` [Intel-wired-lan] " David Miller
2020-05-17 10:51       ` Vladimir Oltean [this message]
2020-05-17 10:51         ` Vladimir Oltean
2020-05-17 18:45         ` Andrew Lunn
2020-05-17 18:45           ` [Intel-wired-lan] " Andrew Lunn
2020-05-17 19:04           ` Vladimir Oltean
2020-05-17 19:04             ` [Intel-wired-lan] " Vladimir Oltean
2020-05-18 19:05       ` Vinicius Costa Gomes
2020-05-18 19:05         ` [Intel-wired-lan] " Vinicius Costa Gomes
2020-05-18 20:56         ` Jakub Kicinski
2020-05-18 20:56           ` [Intel-wired-lan] " Jakub Kicinski
2020-05-18 22:06           ` Vinicius Costa Gomes
2020-05-18 22:06             ` [Intel-wired-lan] " Vinicius Costa Gomes
2020-05-18 22:22             ` Jakub Kicinski
2020-05-18 22:22               ` [Intel-wired-lan] " Jakub Kicinski
2020-05-18 23:05               ` Vinicius Costa Gomes
2020-05-18 23:05                 ` [Intel-wired-lan] " Vinicius Costa Gomes
2020-05-18 23:09                 ` Jakub Kicinski
2020-05-18 23:09                   ` [Intel-wired-lan] " Jakub Kicinski
2020-05-20 21:42                   ` Andre Guedes
2020-05-20 21:42                     ` Andre Guedes
2020-05-20 22:35                     ` Vinicius Costa Gomes
2020-05-20 22:35                       ` Vinicius Costa Gomes
2020-05-19 16:34             ` Murali Karicheri
2020-05-19 16:34               ` [Intel-wired-lan] " Murali Karicheri
2020-05-19 17:49               ` Vinicius Costa Gomes
2020-05-19 17:49                 ` [Intel-wired-lan] " Vinicius Costa Gomes
2020-05-17 15:06 ` Michael Walle
2020-05-18 13:36   ` Murali Karicheri
2020-05-19 20:41     ` Michael Walle
2020-05-19 14:53 ` Murali Karicheri
2020-05-19 14:53   ` [Intel-wired-lan] " Murali Karicheri
2020-05-19 15:32   ` Vinicius Costa Gomes
2020-05-19 15:32     ` [Intel-wired-lan] " Vinicius Costa Gomes
2020-05-19 16:11     ` Murali Karicheri
2020-05-19 16:11       ` [Intel-wired-lan] " Murali Karicheri
2020-05-19 22:39 ` Andre Guedes
2020-05-19 22:39   ` [Intel-wired-lan] " Andre Guedes
2020-05-19 23:37   ` Vinicius Costa Gomes
2020-05-19 23:37     ` [Intel-wired-lan] " Vinicius Costa Gomes
2020-05-20 12:47     ` Murali Karicheri
2020-05-20 12:47       ` [Intel-wired-lan] " Murali Karicheri
2020-05-20 12:52     ` Joergen Andreasen
2020-05-20 12:52       ` [Intel-wired-lan] " Joergen Andreasen
2020-05-20 21:32       ` Vinicius Costa Gomes
2020-05-20 21:32         ` [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=CA+h21hrg_CeD2-zT+7v3b3hPRFaeggmZC9NqPp+soedCYwG63A@mail.gmail.com \
    --to=olteanv@gmail.com \
    --cc=Jose.Abreu@synopsys.com \
    --cc=davem@davemloft.net \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=m-karicheri2@ti.com \
    --cc=netdev@vger.kernel.org \
    --cc=po.liu@nxp.com \
    --cc=vinicius.gomes@intel.com \
    --cc=vladimir.oltean@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.