On Tue, 9 Jan 2024 15:06:47 -0800 Stephen Hemminger <step...@networkplumber.org> wrote:
> 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? > > > > > > > > 2. Fut
