> > On Mon, 20 Sep 2021 13:23:57 +0000 > "Loftus, Ciara" <ciara.lof...@intel.com> wrote: > > > > -----Original Message----- > > > From: dev <dev-boun...@dpdk.org> On Behalf Of Stephen Hemminger > > > Sent: Friday 3 September 2021 17:15 > > > To: dev@dpdk.org > > > Cc: Stephen Hemminger <step...@networkplumber.org>; > > > sta...@dpdk.org; xiaolong...@intel.com > > > Subject: [dpdk-dev] [PATCH] net/af_xdp: fix support of secondary > process > > > > > > Doing basic operations like info_get or get_stats was broken > > > in af_xdp PMD. The info_get would crash because dev->device > > > was NULL in secondary process. Fix this by doing same initialization > > > as af_packet and tap devices. > > > > > > The get_stats would crash because the XDP socket is not open in > > > primary process. As a workaround don't query kernel for dropped > > > packets when called from secondary process. > > > > > > Note: this does not address the other bug which is that transmitting > > > in secondary process is broken because the send() in tx_kick > > > will fail because XDP socket fd is not valid in secondary process. > > > > Hi Stephen, > > > > Apologies for the delayed reply, I was on vacation. > > > > In the Bugzilla report you suggest we: > > "mark AF_XDP as broken in with primary/secondary > > and return an error in probe in secondary process". > > I agree with this suggestion. However with this patch we still permit > secondary, and just make sure it doesn't crash for get_stats. Did you change > your mind? > > Personally, I would prefer to have primary/secondary either working 100% > or else not allowed at all by throwing an error during probe. What do you > think? Do you have a reason/use case to permit secondary processes despite > some features not being available eg. full stats, tx? > > > > Thanks, > > Ciara > > There are two cases where secondary is useful even if send/receive can't > work from secondary process. > The pdump and proc-info applications can work with these patches. > > I am using XDP over pdump as an easy way to get packets into the code for > testing. > > The flag in the documentation doesn't have a "limited" version. > If you want, will send another patch to disable secondary support.
Thanks for explaining. Since there are use cases for secondary, even if the functionality is limited, I don't think it should be disabled. Since we can't flag it as 'limited' in the feature matrix, could you please add a note about the send/receive limitation in the AF_XDP PMD documentation in a v2? There are already a number of limitations listed, which you can add to. Thanks, Ciara > > Supporting secondary, means adding a mechanism to pass the socket > around.