On 1/10/2024 8:11 PM, Konstantin Ananyev wrote: > > >> -----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?
