Re: [PATCH net-next] net: fec: add XDP_TX feature support

[Alexander Lobakin]

From: Wei Fang <wei.fang@xxxxxxx>
Date: Wed, 19 Jul 2023 03:28:26 +0000

>> -----Original Message-----
>> From: Alexander Lobakin <aleksander.lobakin@xxxxxxxxx>
>> Sent: 2023年7月18日 23:15
>> To: Wei Fang <wei.fang@xxxxxxx>
>> Cc: davem@xxxxxxxxxxxxx; edumazet@xxxxxxxxxx; kuba@xxxxxxxxxx;
>> pabeni@xxxxxxxxxx; ast@xxxxxxxxxx; daniel@xxxxxxxxxxxxx;
>> hawk@xxxxxxxxxx; john.fastabend@xxxxxxxxx; Clark Wang
>> <xiaoning.wang@xxxxxxx>; Shenwei Wang <shenwei.wang@xxxxxxx>;
>> netdev@xxxxxxxxxxxxxxx; dl-linux-imx <linux-imx@xxxxxxx>;
>> linux-kernel@xxxxxxxxxxxxxxx; bpf@xxxxxxxxxxxxxxx
>> Subject: Re: [PATCH net-next] net: fec: add XDP_TX feature support
>>
>> From: Wei Fang <wei.fang@xxxxxxx>
>> Date: Mon, 17 Jul 2023 18:37:09 +0800
>>
>>> The XDP_TX feature is not supported before, and all the frames which
>>> are deemed to do XDP_TX action actually do the XDP_DROP action. So
>>> this patch adds the XDP_TX support to FEC driver.
>>
>> [...]
>>
>>> @@ -3897,6 +3923,29 @@ static int fec_enet_txq_xmit_frame(struct
>> fec_enet_private *fep,
>>>  	return 0;
>>>  }
>>>
>>> +static int fec_enet_xdp_tx_xmit(struct net_device *ndev,
>>> +				struct xdp_buff *xdp)
>>> +{
>>> +	struct xdp_frame *xdpf = xdp_convert_buff_to_frame(xdp);
>>
>> Have you tried avoid converting buff to frame in case of XDP_TX? It would save
>> you a bunch of CPU cycles.
>>
> Sorry, I haven't. I referred to several ethernet drivers about the implementation of
> XDP_TX. Most drivers adopt the method of converting xdp_buff to xdp_frame, and
> in this method, I can reuse the existing interface fec_enet_txq_xmit_frame() to
> transmit the frames and the implementation is relatively simple. Otherwise, there
> will be more changes and more effort is needed to implement this feature.
> Thanks!

No problem, it is just FYI, as we observe worse performance when
convert_buff_to_frame() is used for XDP_TX versus when you transmit the
xdp_buff directly. The main reason is that converting to XDP frame
touches ->data_hard_start cacheline (usually untouched), while xdp_buff
is always on the stack and hot.
It is up to you what to pick for your driver obviously :)

> 
>>> +	struct fec_enet_private *fep = netdev_priv(ndev);
>>> +	struct fec_enet_priv_tx_q *txq;
>>> +	int cpu = smp_processor_id();
>>> +	struct netdev_queue *nq;
>>> +	int queue, ret;
>>> +
>>> +	queue = fec_enet_xdp_get_tx_queue(fep, cpu);
>>> +	txq = fep->tx_queue[queue];
>>> +	nq = netdev_get_tx_queue(fep->netdev, queue);
>>> +
>>> +	__netif_tx_lock(nq, cpu);
>>> +
>>> +	ret = fec_enet_txq_xmit_frame(fep, txq, xdpf, false);
>>> +
>>> +	__netif_tx_unlock(nq);
>>> +
>>> +	return ret;
>>> +}
>>> +
>>>  static int fec_enet_xdp_xmit(struct net_device *dev,
>>>  			     int num_frames,
>>>  			     struct xdp_frame **frames,
>>> @@ -3917,7 +3966,7 @@ static int fec_enet_xdp_xmit(struct net_device
>> *dev,
>>>  	__netif_tx_lock(nq, cpu);
>>>
>>>  	for (i = 0; i < num_frames; i++) {
>>> -		if (fec_enet_txq_xmit_frame(fep, txq, frames[i]) < 0)
>>> +		if (fec_enet_txq_xmit_frame(fep, txq, frames[i], true) < 0)
>>>  			break;
>>>  		sent_frames++;
>>>  	}
>>
> 

Thanks,
Olek