DPDK usage discussions
 help / color / mirror / Atom feed
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
>

      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).