On Mon, 20 Sep 2021 15:09:36 +0000 "Loftus, Ciara" <ciara.lof...@intel.com> wrote:
> > > > 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. Looking at this in more detail, and my recommendation is: For 21.11 release (and mark it as Fixes so it gets backported). Have the driver return -ENOTSUP in secondary process. For 22.03 add real secondary support using the rte_mp_msg to pass necessary state to secondary process. Includes socket (and other memory regions?). The pdump and proc-info cases are only useful for developer testing, and there are other ways to do the same thing.
