From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id E691E6A8B for ; Thu, 9 Oct 2014 12:20:37 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP; 09 Oct 2014 03:18:12 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,683,1406617200"; d="scan'208";a="602749292" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by fmsmga001.fm.intel.com with ESMTP; 09 Oct 2014 03:27:56 -0700 Received: from irsmsx152.ger.corp.intel.com (163.33.192.66) by IRSMSX104.ger.corp.intel.com (163.33.3.159) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 9 Oct 2014 11:27:56 +0100 Received: from irsmsx109.ger.corp.intel.com ([169.254.13.253]) by IRSMSX152.ger.corp.intel.com ([169.254.6.118]) with mapi id 14.03.0195.001; Thu, 9 Oct 2014 11:27:56 +0100 From: "Pattan, Reshma" To: Neil Horman Thread-Topic: [dpdk-dev] [PATCH RFC] librte_reorder: new reorder library Thread-Index: AQHP4iD8VUSlKMAr1kW4CpbNHNbi0ZwmOSrggABKVgCAAQd4wA== Date: Thu, 9 Oct 2014 10:27:55 +0000 Message-ID: <3AEA2BF9852C6F48A459DA490692831FE22552@IRSMSX109.ger.corp.intel.com> References: <3AEA2BF9852C6F48A459DA490692831FE21954@IRSMSX109.ger.corp.intel.com> <20141007112155.GA27719@hmsreliant.think-freely.org> <3AEA2BF9852C6F48A459DA490692831FE2226C@IRSMSX109.ger.corp.intel.com> <20141008191546.GC13306@hmsreliant.think-freely.org> In-Reply-To: <20141008191546.GC13306@hmsreliant.think-freely.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH RFC] librte_reorder: new reorder library 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: Thu, 09 Oct 2014 10:20:38 -0000 > -----Original Message----- > From: Neil Horman [mailto:nhorman@tuxdriver.com] > Sent: Wednesday, October 8, 2014 8:16 PM > To: Pattan, Reshma > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH RFC] librte_reorder: new reorder library >=20 > On Wed, Oct 08, 2014 at 02:11:34PM +0000, Pattan, Reshma wrote: > > > > > > > -----Original Message----- > > > From: Neil Horman [mailto:nhorman@tuxdriver.com] > > > Sent: Tuesday, October 7, 2014 12:22 PM > > > To: Pattan, Reshma > > > Cc: dev@dpdk.org > > > Subject: Re: [dpdk-dev] [PATCH RFC] librte_reorder: new reorder > > > library > > > > > > On Tue, Oct 07, 2014 at 09:33:06AM +0000, Pattan, Reshma wrote: > > > > Hi All, > > > > > > > > I am planning to implement packet reorder library. Details are as > > > > below, > > > please go through them and provide the comments. > > > > > > > > Requirement: > > > > To reorder out of ordered packets that are received > > > > from different > > > cores. > > > > > > > > Usage: > > > > To be used along with distributor library. Next version of > > > > distributor are > > > planned to distribute incoming packets to all worker cores > > > irrespective of the flow type. > > > > In this case to ensure in order delivery of the packets at output > > > > side reorder > > > library will used by the tx end. > > > > > > > > Assumption: > > > > All input packets will be marked with sequence number in seqn > > > > field of mbuf, > > > this will be the reference for reordering at the tx end. > > > > Sequence number will be of type uint32_t. New sequence number > > > > field seqn > > > will be added to mbuf structure. > > > > > > > > Design: > > > > a)There will be reorder buffer(circular buffer) structure > > > > maintained in reorder > > > library to store reordered packets and other details of buffer like > > > head to drain the packet from, min sequence number and other details. > > > > b)Library will provide insert and drain functions > > > > to reorder and fetch > > > out the reordered packets respectively. > > > > c)Users of library should pass the packets to insert functions for = reordering. > > > > > > > > Insertion logic: > > > > Sequence number of current packet will be used to calculate offset > > > > in reorder > > > buffer and write packet to the location in the reorder buffer > > > corresponding to offset. > > > > Offset is calculated as difference of > > > > current packet sequence > > > number and sequence number associated with reorder buffer. > > > > > > > > During sequence number wrapping or wrapping over of reorder buffer > > > > size, > > > before inserting the new packet we should move offset number of > > > packets to other buffer called overflow buffer and advance the head > > > of reorder buffer by "offset-reorder buffer size" and insert the new = packet. > > > > > > > > Insert function: > > > > int rte_reorder_insert(struct rte_reorder_buffer *buffer, struct > > > > rte_mbuf *mbuf); > > > > Note: Other insert function is also under plan to insert burst of p= ackets. > > > > > > > > Reorder buffer: > > > > struct rte_reorder_buffer { > > > > unsigned int size; /* The size (number of entries) of = the buffer. */ > > > > unsigned int mask; /* Mask (size - 1) of the buffer */ > > > > unsigned int head; /* Current head of buffer */ > > > > uint32_t min_seqn; /* latest sequence number associate= d with > buffer > > > */ > > > > struct rte_mbuf *entries[MAX_REORDER_BUFFER_SIZE]; /* > > > > buffer to hold reordered mbufs */ }; > > > > > > > > d)Users can fetch out the reordered packets by drain function > > > > provided by > > > library. Users must pass the mbuf array , drain function should fill > > > passed mbuff array with the reordered buffer packets. > > > > During drain operation, overflow buffer packets will be fetched > > > > out first and > > > then reorder buffer. > > > > > > > > Drain function: > > > > int rte_reorder_drain(struct rte_reorder_buffer > > > > *buffer, struct rte_mbuf **mbufs) > > > > > > > > Thanks, > > > > Reshma > > > > > > > > > > This seems reasonable, but why not integrate it with the distributor > > > library rather than create a separate library for it? It seems as > > > though the distributor library is a pre-requisite for this libraries > > > use anyway, as otherwise there will not be anything to reorder Neil > > > > > > > Hi Neil, > > > > Reorder library should be standalone , as there are many ways that can > > cause out of ordering of packets, I just mentioned future packet distri= butor > enhancements as one of the example for out of ordering. > > Other ways like, users can directly distribute the packets to different= cores via > rings and that causes packet out of ordering as well. > > So, keeping reorder library standalone would be good to work with all p= acket > distribution ways. > > >=20 >=20 > Hmm, ok, that seems reasonable. >=20 > Just out of curiosity, where do you intend to inject the packet sequence = number > for this library? >=20 Sequence number marking can be done in either of these places 1)PMD rx si= de 2) packet distributor process or 3) in application itself. Thanks, Reshma > Neil