From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from m13-148.163.com (m13-148.163.com [220.181.13.148]) by dpdk.org (Postfix) with ESMTP id 8759DB392 for ; Tue, 9 Sep 2014 09:25:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Date:From:Subject:MIME-Version:Message-ID; bh=Oybb0 eVUHxY4aGrILggMII38pl61+T3bG8ZaOV883Jg=; b=hQMsqU+xVNFVIbh6EIJop junYCn4gqAhHC3Xy3D1GIYSc5k9ApzeM5FlaJz88EBV7kNZNzRr6BgIE7NXBvWpS LgCjhjLePHq4nW2Kl1PrOHj1XaXxybs2FRwbzy5XqMTfwzTWanGt9fO40sJPWQFc 0ww1WeFvKaCPxlK7fgysmQ= Received: from zimeiw$163.com ( [101.68.93.182] ) by ajax-webmail-wmsvr148 (Coremail) ; Tue, 9 Sep 2014 15:30:40 +0800 (CST) X-Originating-IP: [101.68.93.182] Date: Tue, 9 Sep 2014 15:30:40 +0800 (CST) From: zimeiw To: "Matthew Hall" X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20140725(28226.6623) Copyright (c) 2002-2014 www.mailtech.cn 163com In-Reply-To: <20140909062016.GA7050@mhcomputing.net> References: <4a71bb41.1307.14857e341d5.Coremail.zimeiw@163.com> <20140909062016.GA7050@mhcomputing.net> X-CM-CTRLDATA: HPKQGGZvb3Rlcl9odG09MTIwNzo4MQ== MIME-Version: 1.0 Message-ID: <790c0993.ae8c.148595253e0.Coremail.zimeiw@163.com> X-CM-TRANSID: lMGowAAXERygrA5UXiicAA--.25248W X-CM-SenderInfo: 52lpvxrz6rljoofrz/1tbiQBQC0lEAJieNJwACs8 X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: dev@dpdk.org Subject: Re: [dpdk-dev] TCP/IP stack for DPDK X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 07:25:41 -0000 CgpoaSwKCgpuZXRkcCBzdGFjayB1c2UgcnRlX21idWYgZGlyZWN0bHksIHNvIG5vIHBhY2tldCBj b3BpZWQgZnJvbSBEUERLIHBvcnQgcXVldWUgdG8gbmV0ZHAgc3RhY2suIG5ldGRwIGZvcndhcmRp bmcgcGVyZm9ybWFuY2UgaXMgc2FtZSBhcyBGcmVlQlNELiAKCgoKQXQgMjAxNC0wOS0wOSAwMjoy MDoxNiwgIk1hdHRoZXcgSGFsbCIgPG1oYWxsQG1oY29tcHV0aW5nLm5ldD4gd3JvdGU6Cj5PbiBU dWUsIFNlcCAwOSwgMjAxNCBhdCAwODo0OTo0NEFNICswODAwLCB6aW1laXcgd3JvdGU6Cj4+IEkg aGF2ZSBwb3J0aW5nIG1ham9yIEZyZWVCU0QgdGNwL2lwIHN0YWNrIHRvIGRwZGsuIG5ldyB0Y3Av aXAgc3RhY2sgaXMgYmFzZWQgCj4+IG9uIGRwZGsgcnRlX21idWYsIHJ0ZV9yaW5nLCBydGVfbWVt b3J5IGFuZCBydGVfdGFibGUuIGl0IGlzIGZhc3RlciB0byAKPj4gZm9yd2FyZGluZyBwYWNrZXRz Lgo+Cj5IZWxsbywKPgo+VGhpcyBpcyBhd2Vzb21lIHdvcmsgdG8gYmUgZG9pbmcgYW5kIGJhZGx5 IG5lZWRlZCB0byB1c2UgRFBESyBmb3IgYW55IEw0IAo+cHVycG9zZXMgd2hlcmUgaXQgaXMgdmVy eSBsaW1pdGVkLiBJJ2xsIGJlIGZvbGxvd2luZyB5b3VyIHByb2dyZXNzLgo+Cj5Zb3UgZGlkbid0 IG1lbnRpb24geW91ciBuYW1lLCBhbmQgY29tcGFyZSB5b3VyIHdvcmsgd2l0aCAKPmh0dHBzOi8v Z2l0aHViLmNvbS9ydW1wa2VybmVsL2RwZGstcnVtcHRjcGlwLyAsIGFuZCB0YWxrIGFib3V0IGJl aGF2aW9yIC8gCj5wZXJmb3JtYW5jZSwgYW5kIGhvdyBsb25nIHlvdSB0aGluayBpdCdsbCB0YWtl LiBJJ20gY3VyaW91cyBpZiB5b3UgY2FuIGdpdmUgCj5zb21lIG1vcmUgY29tbWVudHMuCj4KPkkn bSBpbXBsZW1lbnRpbmcgYW4gUlgtc2lkZSB2ZXJ5IGJhc2ljIHN0YWNrIG15c2VsZi4uLiBidXQg SSdtIG5vdCB1c2luZyBCU0QgCj5zdGFuZGFyZCBBUElzIG9yIGRvaW5nIFRYLXNpZGUgbGlrZSB5 b3VycyB3aWxsIGhhdmUuCj4KPk1hdHRoZXcuCg== >From olivier.matz@6wind.com Tue Sep 9 09:57:48 2014 Return-Path: Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) by dpdk.org (Postfix) with ESMTP id 07557B3A1 for ; Tue, 9 Sep 2014 09:57:48 +0200 (CEST) Received: by mail-we0-f178.google.com with SMTP id q58so4255935wes.9 for ; Tue, 09 Sep 2014 01:02:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=kZquozVu75mM9RRsxAgvGH0aWW14DJM8uzQRbEqGA3g=; b=FWk267u1J7Q1x6FEqxsKzlI1KMKp7fSkavIVhKoL6kFCSHTBcPvXGfu8jHH+0j2BX0 4DA+AiXnt1uri3Z3ehd/WcoXA9sxMdZsRmqgemXGzZypFZ/WF51u0CMxm3GUQ+e0fX7u KwGad9degH8PAUDBf2IOvskVwvDmlz2hC7pj1QE81TepizqC4ALNpLNFu6f7i2UMs9QM sCI2TyTU1VI1BbwvJBn8s0D/JCKPIsh6SvR5yqpj0ax+50cWc+txIfslI8f2FZQc5H6Q P2QgQ03osZefqFjM3f0vScQ+u1Tq2H10G53fo7kuHEqSsZ7fFHRutWGRgECVjcnZ5R8k 1VJw== X-Gm-Message-State: ALoCoQmG0+LOU8ESmss3oaSHTI2UK0etGn5TUTrRAP2d7XJX65lN84v75ntkWDiTrCoI8uyxeTwM X-Received: by 10.180.75.17 with SMTP id y17mr27888236wiv.3.1410249771188; Tue, 09 Sep 2014 01:02:51 -0700 (PDT) Received: from [10.16.0.195] (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by mx.google.com with ESMTPSA id n5sm13879149wja.38.2014.09.09.01.02.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Sep 2014 01:02:50 -0700 (PDT) Message-ID: <540EB428.9060706@6wind.com> Date: Tue, 09 Sep 2014 10:02:48 +0200 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: "Zhang, Helin" , Yerden Zhumabekov , "Richardson, Bruce" , "dev@dpdk.org" References: <1409759378-10113-1-git-send-email-bruce.richardson@intel.com> <1409759378-10113-4-git-send-email-bruce.richardson@intel.com> <540D8228.809@6wind.com> <540D85E0.4030203@sts.kz> <540D903E.1060206@6wind.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 03/13] mbuf: add packet_type field X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 07:57:48 -0000 Hello, On 09/09/2014 05:59 AM, Zhang, Helin wrote: > It is a common field which i40e PMD will use it to store the 'packet type ID'. i40e > hardware can recognize more than a hundred of packet types of received packets, > this is quite useful for upper layer stack or application. So this field is quite useful > and will be filled by PMD. > In ixgbe/igb, it has less than 10 packet types which are marked in offload flags. From > now on, it would be better to have new field here to put the hardware offloaded > packet type in and it could be used for future NICs. > >> >> I'm not saying this field is useless. But even if it's useful for some applications >> like yours, it does not mean that it should go in the generic mbuf structure. >> >> Also, for a new field, we should define who is in charge of filling it. >> Is is the driver? Does it mean that all drivers have to be modified to fill it? Or is >> it just a placeholder for applications? In this case, shouldn't we use >> application-specific metadata? In the other direction (TX), we would also need >> to define if this field must be filled by the application before transmitting a mbuf >> to a driver. > Yes, PMD will fill it. I40e PMD will be the first one, ixgbe/igb can be kept as it is, or > modified to be consistent. It is used for RX side only, and for TX side, it can be > investigated to see if it can be used also. I think some new features in development > can think of that. > Anyway, it is a quite useful field for i40e and future generation of NICs. To me, having the support in a hardware for that feature is not a sufficient reason for adding this field. There are many hardware features that will never be integrated in dpdk. This first version of the patch: - just adds a field that is not used by any code, so it is useless. At least testpmd or an application example should show how to use it. - does not describe what enhancement is provided by adding the field (performance? in this case, numbers + use case would help to convince people). - does not describe what can be the content of the field. Is it a protocol number? - does not explain if all drivers must fill this field. If yes, the patch has to update all drivers. If not, something must be done to mark the packet field as unknown by default. Regards, Olivier