Stanislav Fomichev <sdf@xxxxxxxxxx> writes: > On Fri, Jun 23, 2023 at 4:29 PM Vinicius Costa Gomes > <vinicius.gomes@xxxxxxxxx> wrote: >> >> Stanislav Fomichev <sdf@xxxxxxxxxx> 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: netdev@xxxxxxxxxxxxxxx >> > Signed-off-by: Stanislav Fomichev <sdf@xxxxxxxxxx> >> >> 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
