Issues around packet capture when secondary process is doing rx/tx
Stephen Hemminger
stephen at networkplumber.org
Wed Jan 10 00:07:07 CET 2024
On Tue, 9 Jan 2024 15:06:47 -0800
Stephen Hemminger <stephen at networkplumber.org> wrote:
> On Mon, 8 Jan 2024 15:13:25 +0000
> Konstantin Ananyev <konstantin.ananyev at 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
More information about the dev
mailing list