Andre Guedes <andre.gue...@intel.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
