On Thu, Jun 15, 2023 at 5:36 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote:
>
> Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> writes:
>
> > On Wed, Jun 14, 2023 at 5:00 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote:
> >>
> >> >>
> >> >> It's probably going to work if each driver has a separate set of tx
> >> >> fentry points, something like:
> >> >> {veth,mlx5,etc}_devtx_submit()
> >> >> {veth,mlx5,etc}_devtx_complete()
> >>
> >> I really don't get the opposition to exposing proper APIs; as a
> >> dataplane developer I want to attach a program to an interface. The
> >> kernel's role is to provide a consistent interface for this, not to
> >> require users to become driver developers just to get at the required
> >> details.
> >
> > Consistent interface can appear only when there is a consistency
> > across nic manufacturers.
> > I'm suggesting to experiment in the most unstable way and
> > if/when the consistency is discovered then generalize.
>
> That would be fine for new experimental HW features, but we're talking
> about timestamps here: a feature that is already supported by multiple
> drivers and for which the stack has a working abstraction. There's no
> reason why we can't have that for the XDP path as well.
... has an abstraction to receive, but has no mechanism to set it
selectively per packet and read it on completion.
