> > > > > > > > > > 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.
+1 that sounds reasonable to me. Thanks, Ciara
