netdev - Re: [Intel-wired-lan] [next-queue RFC 0/4] ethtool: Add support for frame preemption

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <874ksamdz3.fsf@intel.com>
Date:   Wed, 20 May 2020 15:35:44 -0700
From:   Vinicius Costa Gomes <vinicius.gomes@...el.com>
To:     Andre Guedes <andre.guedes@...el.com>,
        Jakub Kicinski <kuba@...nel.org>
Cc:     Jose.Abreu@...opsys.com, vladimir.oltean@....com, po.liu@....com,
        m-karicheri2@...com, intel-wired-lan@...ts.osuosl.org,
        netdev@...r.kernel.org, olteanv@...il.com,
        David Miller <davem@...emloft.net>
Subject: Re: [Intel-wired-lan] [next-queue RFC 0/4] ethtool: Add support for frame preemption

Andre Guedes <andre.guedes@...el.com> writes:

>> If standard defines it as per-MAC and we can reasonably expect vendors
>> won't try to "add value" and make it per queue (unlikely here AFAIU),
>> then for this part ethtool configuration seems okay to me.
>
> Before we move forward with this hybrid approach, let's recap a few points that
> we discussed in the previous thread and make sure it addresses them
> properly.

Thanks for bringing them up.

>
> 1) Frame Preemption (FP) can be enabled without EST, as described in IEEE
> 802.1Q. In this case, the user has to create a dummy EST schedule in taprio
> just to be able to enable FP, which doesn't look natural.

What I meant by "dummy" schedule, is to configure taprio without
specifying any "sched-entry". And since we have support for adding
schedules during runtime, this might be even useful in general.

>
> 2) Mpqrio already looks overloaded. Besides mapping traffic classes into
> hardware queues, it also supports different modes and traffic shaping. Do we
> want to add yet another setting to it?

I also don't see this as a problem. The parameters that mqprio has carry
a lot of information, but the number of them is not that big.


Cheers,
-- 
Vinicius