> >> -----Original Message----- > >> From: Stephen Hemminger <step...@networkplumber.org> > >> Sent: Tuesday, January 9, 2024 11:07 PM > >> To: Konstantin Ananyev <konstantin.anan...@huawei.com> > >> Cc: dev@dpdk.org; arshdeep.k...@intel.com; Gowda, Sandesh > >> <sandesh.go...@intel.com>; Reshma Pattan > >> <reshma.pat...@intel.com> > >> Subject: Re: Issues around packet capture when secondary process is doing > >> rx/tx > >> > >> On Mon, 8 Jan 2024 15:13:25 +0000 > >> Konstantin Ananyev <konstantin.anan...@huawei.com> wrote: > >> > >>>> I have been looking at a problem reported by Sandesh > >>>> where packet capture does not work if rx/tx burst is done in secondary > >>>> process. > >>>> > >>>> The root cause is that existing rx/tx callback model just doesn't work > >>>> unless the process doing the rx/tx burst calls is the same one that > >>>> registered the callbacks. > >>>> > >>>> An example sequence would be: > >>>> 1. dumpcap (or pdump) as secondary tells pdump in primary to register > >>>> callback > >>>> 2. secondary process calls rx_burst. > >>>> 3. rx_burst sees the callback but it has pointer pdump_rx which is not > >>>> necessarily > >>>> at same location in primary and secondary process. > >>>> 4. indirect function call in secondary to bad location likely causes > >>>> crash. > >>> > >>> As I remember, RX/TX callbacks were never intended to work over multiple > >>> processes. > >>> Right now RX/TX callbacks are private for the process, different process > >>> simply should not > >>> see/execute them. > >>> I.E. it callbacks list is part of 'struct rte_eth_dev' itself, not the > >>> rte_eth_dev.data that is shared > >>> between processes. > >>> It should be normal, wehn for the same port/queue you will end-up with > >>> different list of callbacks > >>> for different processes. > >>> So, unless I am missing something, I don't see how we can end-up with 3) > >>> and 4) from above: > >>> From my understanding secondary process will never see/call primary's > >>> callbacks. > >>> > >>> About pdump itself, it was a while when I looked at it last time, but as > >>> I remember to start it to work, > >>> server process has to call rte_pdump_init() which in terns register > >>> PDUMP_MP handler. > >>> I suppose for the secondary process to act as a 'pdump server' it needs > >>> to call rte_pdump_init() itself, > >>> though I am not sure such option is supported right now. > >>> > >> > >> Did some more tests with modified testpmd, and reached some conclusions: > >> > >> The logical interface would be to allow rte_pdump_init() to be called by > >> the process that would be using rx/tx burst API's. > >> > >> This doesn't work as it should because the multi-process socket API > >> assumes that the it only runs the server in primary. The secondary > >> can start its own MP thread, but it won't work: > >> > >> Primary EAL: Multi-process socket /var/run/dpdk/rte/mp_socket > >> Secondary: EAL: Multi-process socket > >> /var/run/dpdk/rte/mp_socket_6057_1ccd4157fd5 > >> > >> The problem is when client (pdump or dumpcap) tries to run, it uses the > >> mp_socket > >> in the primary which causes: EAL: Cannot find action: mp_pdump > >> > >> Looks like the whole MP socket mechanism is just not up to this. > >> > >> 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?
