netdev - Re: [PATCH iwl-next v3] ice: add E830 Earliest TxTime First Offload support

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: <edf8c701-fb5c-4af3-ac3a-073c6545bdbe@intel.com>
Date: Thu, 12 Jun 2025 13:56:41 -0700
From: "Greenwalt, Paul" <paul.greenwalt@...el.com>
To: Maciej Fijalkowski <maciej.fijalkowski@...el.com>
CC: <intel-wired-lan@...ts.osuosl.org>, <netdev@...r.kernel.org>, "Aleksandr
 Loktionov" <aleksandr.loktionov@...el.com>
Subject: Re: [PATCH iwl-next v3] ice: add E830 Earliest TxTime First Offload
 support



On 6/11/2025 6:29 AM, Maciej Fijalkowski wrote:
> 2k per device or pf? if per device then what if you have 4 port device on
> system with 384 cores and you load xdp progs on each pf. and then try your
> feature which needs hw tx queues.
> 

Yes, the 2k Tx queues are per device and shared equally by each PF, so a
4-port device will have 512 Tx queues per PF. ETF is enabled on the
queue/classid specified by the user via the ETF Qdisc, so the user
decides which Tx queues have ETF enabled.

> what i was trying to say is that you don't ever call __ice_vsi_get_qs().
> this has an impact on XDP or any other feature that needs hw txqs.
> 

As you mentioned, I don't think it makes sense to enable ETF Qdisc on an
XDP queue. Would you suggest that the driver not support (i.e. block the
users request, XDP and ETF mutual exclusivity)?

>>>
>>
>> Hi Maciej,
>>
>> Thanks for the feedback. The reason for using a separate array for
>> tstamp rings is a hardware limitation: the tstamp ring must always have
>> more descriptors than the corresponding Tx ring, so there isn’t a strict
>> 1:1 mapping. This is due to the hardware’s fetch profile and MDD
>> prevention requirements (mentioned in the commit message).
>>
>> Because of this, it’s not possible to simply add a `tstamp` pointer to
>> each `ice_tx_ring`—the relationship isn’t direct, and the tstamp ring
>> may be shared or sized differently.
> 
> ok - up to you generally.
> 

I'll do some work and testing on your initial suggestion.

>>
>> Regarding the interface, I agree that passing an additional array can be
>> confusing. If you have a suggestion for a cleaner way to handle this
>> (e.g., a new structure or abstraction), I’m open to it.
> 
> keep existing interfaces that work on entire array and have a separate
> call for tstamp ring array as mentioned in initial comment.
> 

Thanks,
Paul