On 02/01/2019 01:19 AM, Maciej Fijalkowski wrote: > Hi! > This patchset tries to address the situation where: > * user loads a particular xdp sample application that does stats polling > * user loads another sample application on the same interface > * then, user sends SIGINT/SIGTERM to the app that was attached as a first one > * second application ends up with an unloaded xdp program > > 1st patch contains a helper libbpf function for getting the map fd by a > given map name. > In patch 2 Jesper removes the read_trace_pipe usage from xdp_redirect_cpu > which > was a blocker for converting this sample to libbpf usage. > 3rd patch updates a bunch of xdp samples to make the use of libbpf. > Patch 4 adjusts RLIMIT_MEMLOCK for two samples touched in this patchset. > In patch 5 extack messages are added for cases where dev_change_xdp_fd returns > with an error so user has an idea what was the reason for not attaching the > xdp program onto interface. > Patch 6 makes the samples behavior similar to what iproute2 does when loading > xdp prog - the "force" flag is introduced. > Patch 7 introduces the libbpf function that will query the driver from > userspace about the currently attached xdp prog id. > > Use it in samples that do polling by checking the prog id in signal handler > and comparing it with previously stored one which is the scope of patch 8. > > Thanks! > > v1->v2: > * add a libbpf helper for getting a prog via relative index > * include xdp_redirect_cpu into conversion > > v2->v3: mostly addressing Daniel's/Jesper's comments > * get rid of the helper from v1->v2 > * feed the xdp_redirect_cpu with program name instead of number > > v3->v4: > * fix help message in xdp_sample_pkts > > v4->v5: > * in get_link_xdp_fd, assign prog_id only when libbpf_nl_get_link returned > with 0 > * add extack messages in dev_change_xdp_fd > * check the return value of bpf_get_link_xdp_id when exiting from sample progs
Series looks good to me, but doesn't apply cleanly, please rebase. Thanks, Daniel
