RE: [xdp-hints] [PATCH bpf-next v7 5/5] igc: Add launch time support to XDP ZC
From: Song, Yoong Siang
Date: Tue Feb 04 2025 - 08:39:39 EST
On Tuesday, February 4, 2025 6:10 PM, Fijalkowski, Maciej <maciej.fijalkowski@xxxxxxxxx> wrote:
>On Tue, Feb 04, 2025 at 08:49:07AM +0800, Song Yoong Siang wrote:
>
>> Enable Launch Time Control (LTC) support for XDP zero copy via XDP Tx
>> metadata framework.
>>
>> This patch has been tested with tools/testing/selftests/bpf/xdp_hw_metadata
>> on Intel I225-LM Ethernet controller. Below are the test steps and result.
>>
>> Test 1: Send a single packet with the launch time set to 1 s in the future.
>>
>> Test steps:
>> 1. On the DUT, start the xdp_hw_metadata selftest application:
>> $ sudo ./xdp_hw_metadata enp2s0 -l 1000000000 -L 1
>>
>> 2. On the Link Partner, send a UDP packet with VLAN priority 1 to port 9091
>> of the DUT.
>>
>> Result:
>> When the launch time is set to 1 s in the future, the delta between the
>> launch time and the transmit hardware timestamp is 0.016 us, as shown in
>> printout of the xdp_hw_metadata application below.
>> 0x562ff5dc8880: rx_desc[4]->addr=84110 addr=84110 comp_addr=84110 EoP
>> rx_hash: 0xE343384 with RSS type:0x1
>> HW RX-time: 1734578015467548904 (sec:1734578015.4675)
>> delta to User RX-time sec:0.0002 (183.103 usec)
>> XDP RX-time: 1734578015467651698 (sec:1734578015.4677)
>> delta to User RX-time sec:0.0001 (80.309 usec)
>> No rx_vlan_tci or rx_vlan_proto, err=-95
>> 0x562ff5dc8880: ping-pong with csum=561c (want c7dd)
>> csum_start=34 csum_offset=6
>> HW RX-time: 1734578015467548904 (sec:1734578015.4675)
>> delta to HW Launch-time sec:1.0000 (1000000.000 usec)
>> 0x562ff5dc8880: complete tx idx=4 addr=4018
>> HW Launch-time: 1734578016467548904 (sec:1734578016.4675)
>> delta to HW TX-complete-time sec:0.0000 (0.016 usec)
>> HW TX-complete-time: 1734578016467548920 (sec:1734578016.4675)
>> delta to User TX-complete-time sec:0.0000
>> (32.546 usec)
>> XDP RX-time: 1734578015467651698 (sec:1734578015.4677)
>> delta to User TX-complete-time sec:0.9999
>> (999929.768 usec)
>> HW RX-time: 1734578015467548904 (sec:1734578015.4675)
>> delta to HW TX-complete-time sec:1.0000 (1000000.016 usec)
>> 0x562ff5dc8880: complete rx idx=132 addr=84110
>>
>> Test 2: Send 1000 packets with a 10 ms interval and the launch time set to
>> 500 us in the future.
>>
>> Test steps:
>> 1. On the DUT, start the xdp_hw_metadata selftest application:
>> $ sudo chrt -f 99 ./xdp_hw_metadata enp2s0 -l 500000 -L 1 > \
>> /dev/shm/result.log
>>
>> 2. On the Link Partner, send 1000 UDP packets with a 10 ms interval and
>> VLAN priority 1 to port 9091 of the DUT.
>>
>> Result:
>> When the launch time is set to 500 us in the future, the average delta
>> between the launch time and the transmit hardware timestamp is 0.016 us,
>> as shown in the analysis of /dev/shm/result.log below. The XDP launch time
>> works correctly in sending 1000 packets continuously.
>> Min delta: 0.005 us
>> Avr delta: 0.016 us
>> Max delta: 0.031 us
>> Total packets forwarded: 1000
>>
>> Signed-off-by: Song Yoong Siang <yoong.siang.song@xxxxxxxxx>
>> ---
>> drivers/net/ethernet/intel/igc/igc_main.c | 42 +++++++++++++++++++++--
>> 1 file changed, 40 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/intel/igc/igc_main.c
>b/drivers/net/ethernet/intel/igc/igc_main.c
>> index c3edd8bcf633..535d340c71c9 100644
>> --- a/drivers/net/ethernet/intel/igc/igc_main.c
>> +++ b/drivers/net/ethernet/intel/igc/igc_main.c
>> @@ -2951,9 +2951,33 @@ static u64 igc_xsk_fill_timestamp(void *_priv)
>> return *(u64 *)_priv;
>> }
>>
>> +static void igc_xsk_request_launch_time(u64 launch_time, void *_priv)
>> +{
>> + struct igc_metadata_request *meta_req = _priv;
>> + struct igc_ring *tx_ring = meta_req->tx_ring;
>> + __le32 launch_time_offset;
>> + bool insert_empty = false;
>> + bool first_flag = false;
>> +
>> + if (!tx_ring->launchtime_enable)
>> + return;
>> +
>> + launch_time_offset = igc_tx_launchtime(tx_ring,
>> + ns_to_ktime(launch_time),
>> + &first_flag, &insert_empty);
>> + if (insert_empty) {
>> + igc_insert_empty_packet(tx_ring);
>> + meta_req->tx_buffer =
>> + &tx_ring->tx_buffer_info[tx_ring->next_to_use];
>
>in this case I think you currently are leaking the skbs and dma mappings
>that igc_init_empty_frame() did. you're going to mix
>IGC_TX_BUFFER_TYPE_XSK with IGC_TX_BUFFER_TYPE_SKB and the latter is not
>explicitly initialized. Even though IGC_TX_BUFFER_TYPE_SKB happens to be
>equal to 0, igc_tx_buffer::type is never cleared in the tx clean desc
>routine.
>
Hi Fijalkowski Maciej,
Thanks for your inputs.
Yes, you are right, IGC_TX_BUFFER_TYPE_SKB is mixed together with
IGC_TX_BUFFER_TYPE_XSK. Regarding the skb and dma map,
following code in igc_clean_tx_irq() will free the skb and unmap the dma,
Do these answer your concern on leaking?
igc_main.c:3133: case IGC_TX_BUFFER_TYPE_SKB:
igc_main.c-3134- napi_consume_skb(tx_buffer->skb, napi_budget);
igc_main.c-3135- igc_unmap_tx_buffer(tx_ring->dev, tx_buffer);
igc_main.c-3136- break;
Regarding the igc_tx_buffer::type never cleared, I think the
important thing is making the igc_tx_buffer::next_to_watch NULL
to indicate no remaining packet. Since transmit function will
always set the igc_tx_buffer::type to a proper type,
I think it is optional for us to clear it.
Is that make sense to you?
>> + }
>> +
>> + igc_tx_ctxtdesc(tx_ring, launch_time_offset, first_flag, 0, 0, 0);
>> +}
>> +
>> const struct xsk_tx_metadata_ops igc_xsk_tx_metadata_ops = {
>> .tmo_request_timestamp = igc_xsk_request_timestamp,
>> .tmo_fill_timestamp = igc_xsk_fill_timestamp,
>> + .tmo_request_launch_time = igc_xsk_request_launch_time,
>> };
>>
>> static void igc_xdp_xmit_zc(struct igc_ring *ring)
>> @@ -2976,7 +3000,13 @@ static void igc_xdp_xmit_zc(struct igc_ring *ring)
>> ntu = ring->next_to_use;
>> budget = igc_desc_unused(ring);
>>
>> - while (xsk_tx_peek_desc(pool, &xdp_desc) && budget--) {
>> + /* Packets with launch time require one data descriptor and one context
>> + * descriptor. When the launch time falls into the next Qbv cycle, we
>> + * may need to insert an empty packet, which requires two more
>> + * descriptors. Therefore, to be safe, we always ensure we have at least
>> + * 4 descriptors available.
>> + */
>> + while (xsk_tx_peek_desc(pool, &xdp_desc) && budget >= 4) {
>> struct igc_metadata_request meta_req;
>> struct xsk_tx_metadata *meta = NULL;
>> struct igc_tx_buffer *bi;
>> @@ -3000,6 +3030,12 @@ static void igc_xdp_xmit_zc(struct igc_ring *ring)
>> xsk_tx_metadata_request(meta, &igc_xsk_tx_metadata_ops,
>> &meta_req);
>>
>> + /* xsk_tx_metadata_request() may have updated next_to_use */
>> + ntu = ring->next_to_use;
>> +
>> + /* xsk_tx_metadata_request() may have updated Tx buffer info */
>> + bi = meta_req.tx_buffer;
>> +
>> tx_desc = IGC_TX_DESC(ring, ntu);
>> tx_desc->read.cmd_type_len = cpu_to_le32(meta_req.cmd_type);
>> tx_desc->read.olinfo_status = cpu_to_le32(olinfo_status);
>> @@ -3017,9 +3053,11 @@ static void igc_xdp_xmit_zc(struct igc_ring *ring)
>> ntu++;
>> if (ntu == ring->count)
>> ntu = 0;
>> +
>> + ring->next_to_use = ntu;
>> + budget = igc_desc_unused(ring);
>
>why count the remaining space in loop? couldn't you decrement it
>accordingly to the count of descriptors you have produced? writing ntu
>back and forth between local var and ring struct performance-wise does not
>look fine.
>
Yes, I can check the number of used descriptor in xsk_tx_metadata_request()
by introducing a new field named used_desc in struct igc_metadata_request,
and then decreases the budget with it.
Do this way looked good to you?
Thanks & Regards
Siang
>> }
>>
>> - ring->next_to_use = ntu;
>> if (tx_desc) {
>> igc_flush_tx_descriptors(ring);
>> xsk_tx_release(pool);
>> --
>> 2.34.1
>>