Re: dumpcap: weird failure with six IPv6 hosts in the filter

[Isaac Boukris <iboukris@gmail.com>]

On Mon, Jun 17, 2024 at 6:57 PM Isaac Boukris <iboukris@gmail.com> wrote:
>
> On Mon, Jun 17, 2024 at 6:30 PM Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> >
> > On Mon, 17 Jun 2024 10:11:47 +0300
> > Isaac Boukris <iboukris@gmail.com> wrote:
> >
> > > Hi Stephen,
> > >
> > > For instance, the following filter fais as follows (if I omit one host
> > > it works):
> > > -f "host 1::1 or host 1::1 or host 1::1 or host 1::1 or host 1::1 or host 1::1"
> > >
> > > EAL: Error - exiting with code: 1
> > >   Cause: Packet dump enable on 0:0000:13:00.0 failed Connection timed out
> > >
> > > On the server side I see:
> > > Jun 16 15:17:08: EAL: failed to send to
> > > (/tmp/dpdk/rte/mp_socket_262131_4a103955de0b7a) due to No such file or
> > > directory
> > > Jun 16 15:17:08: pdump_server(): failed to send to client:No such file
> > > or directory
> > > Jun 16 15:17:08: EAL: Fail to handle message: mp_pdump
> > >
> > > Then subsequent requests fail with (even with no filter):
> > > pdump_register_rx_callbacks(): rx callback for port=0 queue=0, already exists
> > >
> > > I debugged the dpdk-mp-msg thread with gdb, as far as I can tell it
> > > hangs an awful lot of time on rte_bpf_load() (~15 secs in my env), so
> > > the client times out and by the time the server tries to respond the
> > > client socket doesn't exist anymore.
> > >
> > > Thoughts?
> >
> > I tried testing this with current 24.07-rc code base and do not see any problem
> > (don't have real hardware needed to fix vdev to get tap to work).
> >
> > # ./build/app/dpdk-dumpcap -f "host 1::1 or host 1::1 or host 1::1 or host 1::1 or host 1::1 or host 1::1"
> > File: /tmp/dpdk-dumpcap_0_net_tap0_20240617082758.pcapng
> > Capturing on 'net_tap0'
> > Packets captured: 0 ^C
> > Packets received/dropped on interface 'net_tap0': 0/0 (0.0)
>
> Thanks for giving it a try, I had thought it would easily reproduce as
> it does for me (perhaps worth trying adding a host or two).
>
> I'll try a more recent dpdk version (currently running 23.11.0) and
> try to narrow it further otherwise.

Just a quick update that I still see the issue in my env with the
master branch (24.07.0-rc0), I'm now testing by adding the filter to
'sample_filters' in test_bpf.c and running:
time sudo build/app/dpdk-test bpf_convert_autotest

With 5 hosts it takes less than 2 secs, with 6 it takes about 25 secs,
i'll try to strace it maybe.