From: DoHyung Kim <dohyung.kim@fluidic.io>
To: users@dpdk.org
Subject: Re: [dpdk-users] Sent a UDP packet, but length is wrong when captured
Date: Fri, 28 Sep 2018 01:24:36 +0900 [thread overview]
Message-ID: <fcd10428-e609-9598-1bb7-a1e1a9b26bea@fluidic.io> (raw)
In-Reply-To: <6a62642d-5142-a65c-b14b-9da673f6091e@fluidic.io>
FYI,
I tried AF_PACKET PMD instead of libpcap-based one, and it works as
expected.
Reading the source code, PCAP PMD's TX function is really simple and
doesn't seem doing something wrong. So I guess it's a problem with libpcap.
If anyone sees no obvious problem in his/her TX code and libpcap PMD
works weird, I think it's a good idea to switch to AF_PACKET PMD. The
only caveat here is it's not well-documented. I had to consult its
source code to configure it properly.
DoHyung
On 2018년 09월 27일 10:54, DoHyung Kim wrote:
>
> I did some more experiments.
>
> One thing very weird is if I transmit the newly prepended header part
> only, then it is sent out correctly. But the cached part has the
> additional 14 bytes (I guess only 10 bytes addition since Ethernet
> frame's CRC is shown due to verification error) when sent alone. The
> very packet is as received from the PMD only with its ethernet/ip/udp
> headers are stripped off using rte_pktmbuf_adj.
>
> So I guess my problem is not exactly relevant to multi-seg mbuf.
>
> Any clue will be appreciated.
>
> I can copy the cached packet into a new packet after the newly formed
> headers. But I hope to avoid memory copies as much as possible.
>
> Thanks.
>
> DoHyung
>
> On 2018년 09월 27일 03:28, DoHyung Kim wrote:
>> Hi,
>>
>> I'm new to DPDK and having trouble in crafting TX packets.
>>
>> My application receives and caches UDP packets after dropping header
>> part.
>> When clients request, it sends the cached packets after prepending
>> them a new header mbuf
>> (by chaining), which contains all the headers to UDP's filled
>> correctly for targeting the clients.
>> Though I think I'm doing nothing wrong, I see the transmitted
>> ethernet frames are
>> 14 bytes longer than expected.
>>
>> Please see a capture of such a packet from Wireshark below:
>>
>>
>>
>>
>>
>> The multi-seg mbuf is 1370 byte long, but weirdly enough, its 1384
>> when captured back.
>> I'm using libpcap based vdev on loopback interface for testing. And
>> DPDK version is 17.11.3 on Ubuntu 18.04.
>>
>> Any clue?
>>
>> Thanks in advance.
>>
>> DoHyung Kim
>
prev parent reply other threads:[~2018-09-27 16:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-26 18:28 DoHyung Kim
2018-09-27 1:54 ` DoHyung Kim
2018-09-27 16:24 ` DoHyung Kim [this message]
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=fcd10428-e609-9598-1bb7-a1e1a9b26bea@fluidic.io \
--to=dohyung.kim@fluidic.io \
--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).