> >>>> Maybe pdump needs to have its own socket and control thread? > >>>> Or MP socket needs to have some multicast fanout to all secondaries? > >>> > >>> Might be we can do something simpler: pass to pdump_enable(), where we > >>> want to enable it: > >>> on primary (remote_ process or secondary (local) process? > >>> And then for primary send a message over MP socket (as we doing now), and > >>> for secondary (itself) > >>> just do actual pdump enablement on it's own (install callbacks, etc.).
> >>> Yes, in that way, one secondary would not be able to enable/idable pdump > >>> on another secondary, > >>> only on itself, but might be it is not needed? > >>> > >>> > >> > >> How secondary, lets say testpmd secondary, install callbacks without > >> getting 'mp' & 'ring' info from pdump secondary process? > > > > Please see my comment above (I copied it here too): > >> Yes, in that way, one secondary would not be able to enable/disable pdump > >> on another secondary, only on itself, but might be it is not needed? > > > > I saw it Konstantin, but it wasn't clear to me what you are suggesting, > that is why I am asking more. > > Do you suggest when testpmd run as secondary process and doing > forwarding, it should do the tasks of pdump itself and we don't use > pdump at all? > I looked into starting pdump_init in the active secondary process, but that won't work right because the passive secondary won't talk to it over the right unix domain socket. It might be possible to have multiple MP server sockets and use some form of AF_UNIX multicast, but it gets complex to handle. Probably best to skip callbacks for this and use a state flag in eth_dev_driver.
