From: "J.J. Mars" <mars14850@gmail.com>
To: Boris Ouretskey <borisusun@gmail.com>
Cc: users@dpdk.org
Subject: Re: DPDK server packets with AF_PACKET driver are not received by the client connected to the same virtual bridge.
Date: Wed, 9 Nov 2022 16:48:57 +0800 [thread overview]
Message-ID: <CAHUXu_WX6JVFxM0w0eU4OODZhyZzm4pvCsWabDQsdkbY1gRaOA@mail.gmail.com> (raw)
In-Reply-To: <CAG4AAQ2Oc8Ln0Bn++t1C2eAx5FYMe9+qnB45gAs0ckBoQAUu4Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2980 bytes --]
If the nic on docker 1 of echo client can receive replies, the reason
should not be PMD I think.
Did you make sure every field in every layer is completely the same between
eth0 in docker 1 and eth0 in docker 2, and all of them are expected?
Boris Ouretskey <borisusun@gmail.com> 于2022年11月9日周三 03:51写道:
>
>
> Hi
>
> I am trying to run a docker based system in one VM, with some servers
> using the DPDK and facing a very strange issue.
>
> The relevant part of the system is the echo server which is built with
> DPDK library and runs in docker, connected to the virtual bridge (with
> AF_PACKET driver), and echo client built with regular sockets (java
> application). See the drawing below for visual details.
>
> The strange thing is that echo replies sent from DPDK echo server docker
> (Docker2), can be seen in tcpdump in the docker of echo client (Docker1)
> however the application (java client) does not receive it on socket level.
> When the echo server runs as a socket application everything works. Seams
> like OS (linux) decide not to route the packet to the application for
> some reason.
>
> Some quick important notes.
>
> - DPDK layer starts ok and no EAL errors are reported. Its echo replies as
> mentioned before can clearly be seen when capturing traffic on eth0 in
> client docker.
> - It is not the issue of parsing the echo replies on application level. I
> checked the strace logs and cannot see any traffic delivered to the
> application
> - I have compared the captures from working socket based echo server and
> MACs seam to be ok, also the packets sent from DPDK server are formed well.
> - No logs for martian packets when enabled.
>
> I would like to focus the attention of dear DPDK experts on the following
> question: is it possible that DPDK AF_PACKET driver intercepts both packets
> destined to the virtual nic eth0 of Docker1 AND eth0 of Docker2,
> preventing it from being received by application?
>
> DPDK Version 18
>
> VIRTUAL BOX VM (Alma Linux)
>
> Docker1 Docker2
> +---------------+ +------------+
> | | Request | |
> | | --------------> | DPDK |
> | Socket Echo | | Echo Server
> | Client | Reply | Server |
> | | <------------- | |
> --vdev=eth_af_packet0,iface=eth0,qdisc_bypass=1
> | | | |
> | tcpdump -i eth0 +------+-----+
> +-------+-------+ eth0 |
> | eth0 |
> | No IP |
> +------v--------------------------------------v-----+
> | Virtual Docker Bridge |
> +---------------------------------------------------+
>
>
> Thanks
>
[-- Attachment #2: Type: text/html, Size: 3860 bytes --]
next prev parent reply other threads:[~2022-11-09 8:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-08 19:51 Boris Ouretskey
2022-11-09 8:48 ` J.J. Mars [this message]
2022-11-12 17:46 ` Boris Ouretskey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAHUXu_WX6JVFxM0w0eU4OODZhyZzm4pvCsWabDQsdkbY1gRaOA@mail.gmail.com \
--to=mars14850@gmail.com \
--cc=borisusun@gmail.com \
--cc=users@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).