Subject: Re: [RFC bpf-next v2 06/11] net: veth: Implement devtx timestamp kfuncs

From: Vinicius Costa Gomes <[email-masked]>
Date: Mon, 26 Jun 2023 15:00:15 -0700

Stanislav Fomichev <[email-masked]> writes:

> On Fri, Jun 23, 2023 at 4:29 PM Vinicius Costa Gomes
> <[email-masked]> wrote:
>>
>> Stanislav Fomichev <[email-masked]> writes:
>>
>> > Have a software-based example for kfuncs to showcase how it
>> > can be used in the real devices and to have something to
>> > test against in the selftests.
>> >
>> > Both path (skb & xdp) are covered. Only the skb path is really
>> > tested though.
>> >
>> > Cc: [email-masked]
>> > Signed-off-by: Stanislav Fomichev <[email-masked]>
>>
>> Not really related to this patch, but to how it would work with
>> different drivers/hardware.
>>
>> In some of our hardware (the ones handled by igc/igb, for example), the
>> timestamp notification comes some time after the transmit completion
>> event.
>>
>> From what I could gather, the idea would be for the driver to "hold" the
>> completion until the timestamp is ready and then signal the completion
>> of the frame. Is that right?
>
> Yeah, that might be the option. Do you think it could work?
>

For the skb and XDP cases, yeah, just holding the completion for a while
seems like it's going to work.

XDP ZC looks more complicated to me, not sure if it's only a matter of
adding something like:

void xsk_tx_completed_one(struct xsk_buff_pool *pool, struct xdp_buff *xdp);

Or if more changes would be needed. I am trying to think about the case
that the user sent a single "timestamp" packet among a bunch of
"non-timestamp" packets.

Cheers,
-- 
Vinicius