From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com [209.85.215.182]) by dpdk.org (Postfix) with ESMTP id A8EDC1B1AD for ; Thu, 27 Sep 2018 03:54:26 +0200 (CEST) Received: by mail-pg1-f182.google.com with SMTP id y18-v6so694849pge.0 for ; Wed, 26 Sep 2018 18:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fluidic-io.20150623.gappssmtp.com; s=20150623; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=+orhFL5m5hDCfk6JnSNKo7CCDR5xPIr1uvmT3lhSWLE=; b=XIUNn8kK4UI+UQrS3hfFy58OB28obfRL9fBPeW9v++Zt7+PQ80jFhYQwWB8t8aesMC k2fc4yxMdtCZ7QKY9CQRIurLfuWUVpRKrPDy9vWdOYg8aVed2vF9nfjSOdHBmyYX4l3K Ddt7hKCfbLMS+WfqW+p3dandqPCLuEilSLRHE5gdt9oaa0n/+rw2fExpM2VmwT726hxu tPd17PSDWKxmvaru6aJ5nMbCd8/wrid+g+ct7GWig7kxP8JoIxKlgzPiLsQueBQ4zyal wOCi5BwO5ZtI0R56MkDtpUlimPzOzKzVQcfeucXVTnwLFnF2gMIQ1FYItEyf42EVZ8fb 2gvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=+orhFL5m5hDCfk6JnSNKo7CCDR5xPIr1uvmT3lhSWLE=; b=UqaMhHw8xROY25nvyRnO+hcAng//E/1UEhMqoGTawNkQpk/6e52dmB/F2H1AeQGFDy 1p+z4mHqXs5NXe2BySijta01Tf0zKKMv73Ogk495D1FiyLVXMSPx4AYaspp/L1NTGheh iwDyKpQYiTMPYywMS1w2gMvwPCGt2Z2KrTRPvKglqAtHksAbScHKDSxAjL4+uEIIVnf5 i+hErjtLLGj6vRG/BwX+p68ux2rVUpx0Xm82+hBKz55ESwPbfaMFGY7V48s10jN3ezHd 5XXHWeYbcbOik4/OV3zeQwu14M7i0nTY8TB7khPMbuTIFch73HXvJCOMPmuUrvnoouN3 7c5A== X-Gm-Message-State: ABuFfogleP1Qsi+EBMReN96D06Ld2MCpKViBRTcReWXfpjnEc8jhLpJv b8TSWqcURDmbr3oU2kHP+J01LoytGuE= X-Google-Smtp-Source: ACcGV61pqfEwLjY3eYFR92QnVfBcmXSwXga1OhJA5s9/fpkKG8zwcsM+e72xU6xBevGAPB5a3mnIYQ== X-Received: by 2002:a17:902:9a45:: with SMTP id x5-v6mr8161970plv.213.1538013265368; Wed, 26 Sep 2018 18:54:25 -0700 (PDT) Received: from [192.168.0.111] ([121.166.61.79]) by smtp.gmail.com with ESMTPSA id f15-v6sm414731pgv.66.2018.09.26.18.54.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Sep 2018 18:54:24 -0700 (PDT) From: DoHyung Kim To: users@dpdk.org References: <034c4fb9-0f1d-78b7-0caf-6cb8c9ce2f09@fluidic.io> Message-ID: <6a62642d-5142-a65c-b14b-9da673f6091e@fluidic.io> Date: Thu, 27 Sep 2018 10:54:21 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <034c4fb9-0f1d-78b7-0caf-6cb8c9ce2f09@fluidic.io> Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-users] Sent a UDP packet, but length is wrong when captured X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2018 01:54:27 -0000 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