From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by dpdk.org (Postfix) with ESMTP id 8167868D9 for ; Fri, 4 Oct 2013 20:08:51 +0200 (CEST) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 04 Oct 2013 11:09:34 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.90,1034,1371106800"; d="scan'208";a="369920791" Received: from orsmsx108.amr.corp.intel.com ([10.22.240.6]) by azsmga001.ch.intel.com with ESMTP; 04 Oct 2013 11:09:12 -0700 Received: from orsmsx156.amr.corp.intel.com (10.22.240.22) by ORSMSX108.amr.corp.intel.com (10.22.240.6) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 4 Oct 2013 11:09:11 -0700 Received: from orsmsx102.amr.corp.intel.com ([169.254.1.143]) by ORSMSX156.amr.corp.intel.com ([169.254.8.156]) with mapi id 14.03.0123.003; Fri, 4 Oct 2013 11:09:11 -0700 From: "Venkatesan, Venky" To: Stephen Hemminger , jigsaw Thread-Topic: [dpdk-dev] Need comment on 82599 TSO Thread-Index: AQHOwSCvaSl5AAMYz06nWgZrOK7v4Jnk1I2A Date: Fri, 4 Oct 2013 18:09:10 +0000 Message-ID: <1FD9B82B8BF2CF418D9A1000154491D973F58E2A@ORSMSX102.amr.corp.intel.com> References: <20131004094122.0166e406@nehalam.linuxnetplumber.net> In-Reply-To: <20131004094122.0166e406@nehalam.linuxnetplumber.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] Need comment on 82599 TSO 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: Fri, 04 Oct 2013 18:08:52 -0000 Stephen,=20 Agree. Growing to two cache lines is an inevitability. Re-organizing the mb= uf a bit to alleviate some of the immediate space with as minimal a perform= ance as possible (including separating the QoS fields out completely into i= ts own separate area) is a good idea - the first cache line would be packet= + mbuf related information, the second more of the metadata that we need. = Any suggestions on how many bytes would be needed for QoS?=20 Qinglai,=20 For your TSO implementation patch, let's work the patch as is (assuming the= mbuf grows) - add the 16 bits into the pktmbuf structure (and it will grow= beyond a cache line). We can get some performance numbers for the standard= benchmarks. I will look at a few ideas to free up some space in the mbuf t= o keep the packet related stuff within the first cache line while keeping p= erformance close to where it is today. Regards,=20 -Venky -----Original Message----- From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen Hemminger Sent: Friday, October 04, 2013 9:41 AM To: jigsaw Cc: dev@dpdk.org Subject: Re: [dpdk-dev] Need comment on 82599 TSO On Fri, 4 Oct 2013 15:44:19 +0300 jigsaw wrote: > Hi, >=20 > I'm working on TSO for 82599, and encounter a problem: nowhere to store M= SS. >=20 > TSO must be aware of MSS, or gso in skb of kernel. > But MSS nees 16 bits per mbuf. And we have no spare 16 bits in=20 > rte_mbuf or rte_pktmbuf. > If we add 16 bit field in rte_pktmbuf, the size of rte_mbuf will be=20 > doubled, coz currently the size is at the edge of cacheline(32 byte). >=20 > I have two solutions here: >=20 > 1. Store MSS in struct rte_eth_conf. > This is actually a very bad idea, coz MSS is not bound to device. >=20 > 2. Turn on and off TSO with rte_ctrlmbuf. > I found that rte_ctrlmbuf is not used at all. So it could be the first=20 > use case of it. > With rte_ctrlmbuf we have enough space to store MSS. >=20 > Looking forward to your comments. >=20 > thx & > rgds, > -Qinglai The mbuf needs to grow to 2 cache lines. There are other things that need t= o be added to mbuf eventually as well. For example the QoS bitfield is too = small when crammed into 32 bits. Ideally the normal small packet stuff woul= d be in the first cacheline; and the other part of the struct would have th= ings less likely to be used.