Hi Vinicius,

On 03/12/2020 07:34 PM, Vinicius Costa Gomes wrote:

Hi,

Po Liu [off-list ref] writes:

quoted

Hi Vinicius,


Br,
Po Liu

quoted

-----Original Message-----
From: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Sent: 2020年2月22日 5:44
To: Po Liu <redacted>; davem@davemloft.net;
hauke.mehrtens@intel.com; gregkh@linuxfoundation.org; allison@lohutok.net;
tglx@linutronix.de; hkallweit1@gmail.com; saeedm@mellanox.com;
andrew@lunn.ch; f.fainelli@gmail.com; alexandru.ardelean@analog.com;
jiri@mellanox.com; ayal@mellanox.com; pablo@netfilter.org; linux-
kernel@vger.kernel.org; netdev@vger.kernel.org
Cc: simon.horman@netronome.com; Claudiu Manoil
[off-list ref]; Vladimir Oltean [off-list ref];
Alexandru Marginean [off-list ref]; Xiaoliang Yang
[off-list ref]; Roy Zang [off-list ref]; Mingkai Hu
[off-list ref]; Jerry Huang [off-list ref]; Leo Li
[off-list ref]; Po Liu [off-list ref]
Subject: [EXT] Re: [v1,net-next, 1/2] ethtool: add setting frame preemption of
traffic classes

Caution: EXT Email

Hi,

Po Liu [off-list ref] writes:

quoted

IEEE Std 802.1Qbu standard defined the frame preemption of port
traffic classes. This patch introduce a method to set traffic classes
preemption. Add a parameter 'preemption' in struct
ethtool_link_settings. The value will be translated to a binary, each
bit represent a traffic class. Bit "1" means preemptable traffic
class. Bit "0" means express traffic class.  MSB represent high number
traffic class.

If hardware support the frame preemption, driver could set the
ethernet device with hw_features and features with NETIF_F_PREEMPTION
when initializing the port driver.

User can check the feature 'tx-preemption' by command 'ethtool -k
devname'. If hareware set preemption feature. The property would be a
fixed value 'on' if hardware support the frame preemption.
Feature would show a fixed value 'off' if hardware don't support the
frame preemption.

Command 'ethtool devname' and 'ethtool -s devname preemption N'
would show/set which traffic classes are frame preemptable.

Port driver would implement the frame preemption in the function
get_link_ksettings() and set_link_ksettings() in the struct ethtool_ops.

Any updates on this series? If you think that there's something that I could help,
just tell.

Sorry for the long time not involve the discussion. I am focus on other tsn code for tc flower.
If you can take more about this preemption serial, that would be good.

I summary some suggestions from Marali Karicheri and Ivan Khornonzhuk and by you and also others:
- Add config the fragment size, hold advance, release advance and flags;
     My comments about the fragment size is in the Qbu spec limit the fragment size " the minimum non-final fragment size is 64,
128, 192, or 256 octets " this setting would affect the guardband setting for Qbv. But the ethtool setting could not involve this issues but by the taprio side.
- " Furthermore, this setting could be extend for a serial setting for mac and traffic class."  "Better not to using the traffic class concept."
    Could adding a serial setting by "ethtool --preemption xxx" or other name. I don' t think it is good to involve in the queue control since queues number may bigger than the TC number.
- The ethtool is the better choice to configure the preemption
   I agree.

Just a quick update. I was able to dedicate some time to this, and have
something aproaching RFC-quality, but it needs more testing.

Great! I have got my frame preemption working on my SoC. Currently I am
using some defaults. I test it by using statistics provided by the
SoC. I will be able to integrate and test your patch using my internal
version and will include it in my patch to upstream once I am ready.

Regards,

Murali

So, question, what were you using for testing this? Anything special?

And btw, thanks for the summary of the discussion.

quoted

Thanks！

quoted

Cheers,
--
Vinicius

-- 
Murali Karicheri
Texas Instruments