[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKH8qBt1GHnY2jVac--xymN-ch8iCDftiBckzp9wvTJ7k-3zAg@mail.gmail.com>
Date: Mon, 26 Jun 2023 10:00:11 -0700
From: Stanislav Fomichev <sdf@...gle.com>
To: Vinicius Costa Gomes <vinicius.gomes@...el.com>
Cc: bpf@...r.kernel.org, ast@...nel.org, daniel@...earbox.net,
andrii@...nel.org, martin.lau@...ux.dev, song@...nel.org, yhs@...com,
john.fastabend@...il.com, kpsingh@...nel.org, haoluo@...gle.com,
jolsa@...nel.org, netdev@...r.kernel.org
Subject: Re: [RFC bpf-next v2 06/11] net: veth: Implement devtx timestamp kfuncs
On Fri, Jun 23, 2023 at 4:29 PM Vinicius Costa Gomes
<vinicius.gomes@...el.com> wrote:
>
> Stanislav Fomichev <sdf@...gle.com> 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@...r.kernel.org
> > Signed-off-by: Stanislav Fomichev <sdf@...gle.com>
>
> 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?
Powered by blists - more mailing lists