On Tue, Mar 26, 2019 at 5:13 PM Jonathan Lemon <b...@fb.com> wrote: > > The rationale (IIRC) was that it would be easier for new users to > get started using AF_XDP by providing everything that was needed > by default. > > Passing in XSK_LIBBPF_FLAGS__INHIBIT_PROG to the library will > bypass loading the sample program, so a user application may still > use the library with their own bpf program. > > I'll admit that the change likely makes it harder to simply modify > the sample program for other uses, but that's not really the point > of the samples. > -- > Jonathan > > On 26 Mar 2019, at 8:46, Maxim Mikityanskiy wrote: > > > Hi Magnus and all, > > > > https://patchwork.ozlabs.org/cover/1045921/ > > > > This series removes xdpsock_kern.c and replaces it by the bytecode > > hardcoded in libbpf. I am wondering whether there is some real issue > > with having the XDP program in a separate C file, just like before, > > because this change made it far less convenient to modify the XDP > > program. Could you give any comments? > > > > Thanks, > > Max
How about we reintroduce a sample C XDP program once we have a reason to use one in the xdpsock program, i.e. for something not covered by libbpf? I do not have such a use case at the moment, but do you Max? If so, as you say, it would be good to have an example on how to accomplish this using the XSK_LIBBPF_FLAGS__INHIBIT_PROG that Jonathan mentioned. /Magnus
