On Tue, Jun 13, 2023 at 9:00 PM Stanislav Fomichev <sdf@xxxxxxxxxx> wrote:
>
> On Tue, Jun 13, 2023 at 7:55 AM Willem de Bruijn
> <willemdebruijn.kernel@xxxxxxxxx> wrote:
> >
> > On Mon, Jun 12, 2023 at 7:24 PM Stanislav Fomichev <sdf@xxxxxxxxxx> wrote:
> > >
> > > devtx is a lightweight set of hooks before and after packet transmission.
> > > The hook is supposed to work for both skb and xdp paths by exposing
> > > a light-weight packet wrapper via devtx_frame (header portion + frags).
> > >
> > > devtx is implemented as a tracing program which has access to the
> > > XDP-metadata-like kfuncs. The initial set of kfuncs is implemented
> > > in the next patch, but the idea is similar to XDP metadata:
> > > the kfuncs have netdev-specific implementation, but common
> > > interface. Upon loading, the kfuncs are resolved to direct
> > > calls against per-netdev implementation. This can be achieved
> > > by marking devtx-tracing programs as dev-bound (largely
> > > reusing xdp-dev-bound program infrastructure).
> > >
> > > Attachment and detachment is implemented via syscall BPF program
> > > by calling bpf_devtx_sb_attach (attach to tx-submission)
> > > or bpf_devtx_cp_attach (attach to tx completion). Right now,
> > > the attachment does not return a link and doesn't support
> > > multiple programs. I plan to switch to Daniel's bpf_mprog infra
> > > once it's available.
> > >
> > > Cc: netdev@xxxxxxxxxxxxxxx
> > > Signed-off-by: Stanislav Fomichev <sdf@xxxxxxxxxx>
> >
> >
> > > @@ -2238,6 +2238,8 @@ struct net_device {
> > > unsigned int real_num_rx_queues;
> > >
> > > struct bpf_prog __rcu *xdp_prog;
> > > + struct bpf_prog __rcu *devtx_sb;
> > > + struct bpf_prog __rcu *devtx_cp;
> >
> > nit/subjective: non-obvious two letter acronyms are nr. How about tx
> > and txc (or txcomp)
>
> devtx and devtxc? I was using devtxs vs devtxc initially, but that
> seems confusing. I can probably spell them out here:
> devtx_submit
> devtx_complete
>
> Should probably be better?
That's more clear, thanks.
