netdev - Re: [PATCH net-next 5/7] sfc: de-indirect TSO handling

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <e6009413-aba0-b0de-ba66-71d64bd4b86b@solarflare.com>
Date:   Fri, 11 Sep 2020 18:42:34 +0100
From:   Edward Cree <ecree@...arflare.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     <linux-net-drivers@...arflare.com>, <davem@...emloft.net>,
        <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 5/7] sfc: de-indirect TSO handling

On 11/09/2020 17:01, Jakub Kicinski wrote:
> On Thu, 10 Sep 2020 21:33:11 +0100 Edward Cree wrote:
>> index 078c7ec2a70e..272eb5ecb7e7 100644
>> --- a/drivers/net/ethernet/sfc/ef100_tx.c
>> +++ b/drivers/net/ethernet/sfc/ef100_tx.c
>> @@ -38,7 +38,8 @@ void ef100_tx_init(struct efx_tx_queue *tx_queue)
>>  				    tx_queue->channel->channel -
>>  				    tx_queue->efx->tx_channel_offset);
>>  
>> -	if (efx_mcdi_tx_init(tx_queue, false))
>> +	tx_queue->tso_version = 3;
>> +	if (efx_mcdi_tx_init(tx_queue))
>>  		netdev_WARN(tx_queue->efx->net_dev,
>>  			    "failed to initialise TXQ %d\n", tx_queue->queue);
>>  }
>> --- a/drivers/net/ethernet/sfc/tx.c
>> +++ b/drivers/net/ethernet/sfc/tx.c
>> @@ -338,8 +338,18 @@ netdev_tx_t __efx_enqueue_skb(struct efx_tx_queue *tx_queue, struct sk_buff *skb
>>  	 * size limit.
>>  	 */
>>  	if (segments) {
>> -		EFX_WARN_ON_ONCE_PARANOID(!tx_queue->handle_tso);
>> -		rc = tx_queue->handle_tso(tx_queue, skb, &data_mapped);
>> +		switch (tx_queue->tso_version) {
>> +		case 1:
>> +			rc = efx_enqueue_skb_tso(tx_queue, skb, &data_mapped);
>> +			break;
>> +		case 2:
>> +			rc = efx_ef10_tx_tso_desc(tx_queue, skb, &data_mapped);
>> +			break;
>> +		case 0: /* No TSO on this queue, SW fallback needed */
>> +		default:
>> +			rc = -EINVAL;
>> +			break;
>> +		}
> Should tso_version 3 be handled in this switch?
No, because this switch is in the EF10/Siena datapath and is neverrun for
 EF100.  Setting tx_queue->tso_version = 3 for EF100 is really just there
 as documentation — EF100 has a completely different TX path, in
 ef100_enqueue_skb(), which never looks at tx_queue->tso_version because
 currently there's only one version of EF100 TSO descriptor.  From a
 functional perspective everything would still work if it were set to 0,
 but that would be kinda misleading.
Should I explain this in the commit message, or in a comment (and if the
 latter, where should it go?)

-ed