On Fri, Jun 4, 2021 at 9:52 PM Kumar Kartikeya Dwivedi <memxor@xxxxxxxxx> wrote:
>
> On Fri, Jun 04, 2021 at 11:31:57PM IST, Alexei Starovoitov wrote:
> > On Fri, Jun 04, 2021 at 12:01:15PM +0530, Kumar Kartikeya Dwivedi wrote:
> > > +/* TC bpf_link related API */
> > > +struct bpf_tc_hook;
> > > +
> > > +struct bpf_tc_link_opts {
> > > + size_t sz;
> > > + __u32 handle;
> > > + __u32 priority;
> > > + __u32 gen_flags;
> > > + size_t :0;
> > > +};
> >
> > Did you think of a way to share struct bpf_tc_opts with above?
> > Or use bpf_tc_link_opts inside bpf_tc_opts?
>
> A couple of fields in bpf_tc_opts aren't really relevant here (prog_fd, prog_id)
> and will always be unused, so I thought it would be cleaner to give this its own
> opts struct. It still reuses the hook abstraction that was added, though.
Overall probably it will be less confusing to have one _opts struct
across both APIs, even if some of the fields are not used. Just
enforce that they are always NULL (and document in a comment that for
bpf_link-based API it's not expected).
>
> > Some other way?
> > gen_flags here and flags there are the same?
>
> No, it was an oversight that I missed adding gen_flags there, I'll send a patch
> separately with some other assorted things. It's used when offloading to HW.
>
> We don't really support any other flags (e.g. BPF_TC_F_REPLACE) for this.
>
> --
> Kartikeya
