From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-f180.google.com (mail-pg1-f180.google.com [209.85.215.180]) by dpdk.org (Postfix) with ESMTP id 1ED5B1B485 for ; Thu, 27 Sep 2018 18:24:41 +0200 (CEST) Received: by mail-pg1-f180.google.com with SMTP id g2-v6so2315736pgu.11 for ; Thu, 27 Sep 2018 09:24:41 -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=NaYm9scW+XGWYfRhzCD4tTmvqdYDRIzZyQKurAYraSU=; b=B7KOywSz3dAw+8/6kd5v5Sjlp6sYaW3emSPue9r0xd3HdOi0btmYgzeEa0M97YN3NA CTYlPqXWUGF1Lt5V48/BJZQL0ZLrvHBvSUKAB/OvvCSSkdyY5C1HVa3YUsC60hGb+0ue NunqOfMnf33/5rJhm/bsePwUJ021o3wsMKJAaX6G4yfk3nRo0YrKgcaK6ClRYyRgIrFX l3Ji7NTvD8GyVGblzlauqubj90aPG2zApR8lIgpe3v3oJ2Klx/pC81MnObat94A+dQJf 9TvqJ45dkguCU6d6fb/GqGN9Nl+2JQcSf6t3NZ7gVr67DLPCv2g/rYE3hnrESwEjXCxC ohdQ== 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=NaYm9scW+XGWYfRhzCD4tTmvqdYDRIzZyQKurAYraSU=; b=Mo5DYl//vXGD1ui6lmd+lCiAAm1d9RzU4T4ArgU7ihgH5VoYTNPZQkfPa/SpLTs23M l3PZHbXo+xHUjlQahmlUFVLg/Bat6Sg6/0KzeLo4rSYvHMSSjKqz8O0OhDOTBSzd7oOz HANsOnsquB2QZrK9uctPdVh4hVITNsJxiVuLmmVCn0XMdJ9y9YHdhfFiLq5rRUe7VRzs 2Fv+asLWy97UXrYdwy2BF9WSKC99ZlQkqRel5gQPSuKYJODebrmJ/Spk+jmZdUF86uPf oA89kVSvyHh3JpuoX60xnG6xk3PFWcsuwEkkO9BlHhCOTIG7hGB5j1qVfTshlZDrFtr8 +vrA== X-Gm-Message-State: ABuFfoiXJZDphpFWYapZdx9OZr59/GFm8+/Dehpv8lWw/iHL/f2QeRvp qTd1iPmDBYGkVMG/WXBfqYEmH782phg= X-Google-Smtp-Source: ACcGV611nnYDfvrAQi60QlNbKpXthky8OIuM6A3KBaGgxsIB8XL1imA1NHITE3xvia79d0QcE6EP9Q== X-Received: by 2002:a62:18a:: with SMTP id 132-v6mr12401821pfb.207.1538065479962; Thu, 27 Sep 2018 09:24:39 -0700 (PDT) Received: from [192.168.0.111] ([121.166.61.79]) by smtp.gmail.com with ESMTPSA id c5-v6sm4329557pfg.2.2018.09.27.09.24.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Sep 2018 09:24:39 -0700 (PDT) From: DoHyung Kim To: users@dpdk.org References: <034c4fb9-0f1d-78b7-0caf-6cb8c9ce2f09@fluidic.io> <6a62642d-5142-a65c-b14b-9da673f6091e@fluidic.io> Message-ID: Date: Fri, 28 Sep 2018 01:24:36 +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: <6a62642d-5142-a65c-b14b-9da673f6091e@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 16:24:43 -0000 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 >