From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <reshma.pattan@intel.com>
Received: from mga09.intel.com (mga09.intel.com [134.134.136.24])
by dpdk.org (Postfix) with ESMTP id 39BE67DDC
for <dev@dpdk.org>; Thu, 9 Oct 2014 16:29:02 +0200 (CEST)
Received: from orsmga001.jf.intel.com ([10.7.209.18])
by orsmga102.jf.intel.com with ESMTP; 09 Oct 2014 07:29:53 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,685,1406617200"; d="scan'208";a="586066911"
Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159])
by orsmga001.jf.intel.com with ESMTP; 09 Oct 2014 07:36:08 -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 15:36:07 +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 15:36:07 +0100
From: "Pattan, Reshma" <reshma.pattan@intel.com>
To: Neil Horman <nhorman@tuxdriver.com>
Thread-Topic: [dpdk-dev] [PATCH RFC] librte_reorder: new reorder library
Thread-Index: AQHP4iD8VUSlKMAr1kW4CpbNHNbi0ZwmOSrggABKVgCAAQd4wIAACqMAgAAqyHA=
Date: Thu, 9 Oct 2014 14:36:06 +0000
Message-ID: <3AEA2BF9852C6F48A459DA490692831FE22808@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>
<3AEA2BF9852C6F48A459DA490692831FE22552@IRSMSX109.ger.corp.intel.com>
<20141009113650.GB20940@hmsreliant.think-freely.org>
In-Reply-To: <20141009113650.GB20940@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.181]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dev@dpdk.org" <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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Oct 2014 14:29:04 -0000
> -----Original Message-----
> From: Neil Horman [mailto:nhorman@tuxdriver.com]
> Sent: Thursday, October 9, 2014 12:37 PM
> To: Pattan, Reshma
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH RFC] librte_reorder: new reorder library
>=20
> On Thu, Oct 09, 2014 at 10:27:55AM +0000, Pattan, Reshma wrote:
> >
> >
> > > -----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
> > >
> > > 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 packets.
> > > > > >
> > > > > > 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 buffe=
r */
> > > > > > unsigned int head; /* Current head of buffer */
> > > > > > uint32_t min_seqn; /* latest sequence number assoc=
iated 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 distributor
> > > 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 packet
> > > distribution ways.
> > > >
> > >
> > >
> > > Hmm, ok, that seems reasonable.
> > >
> > > Just out of curiosity, where do you intend to inject the packet
> > > sequence number for this library?
> > >
> > Sequence number marking can be done in either of these places 1)PMD r=
x
> side 2) packet distributor process or 3) in application itself.
> >
> Thanks. So, that was the part of this that was getting to me. For this t=
o work,
> you're going to have to mark frames externally to the re-order library (i=
.e.
> You're proposed library needs to rely on the application or the pmd to do=
proper
> marking of frames to reorder properly). Is it tennable in your mind to r=
equire
> that?
>=20
For the users of distributor sequence number marking will be automatic.=20
We are also considering ways to make sequence number marking automatic in P=
MD RX but at cost of performance hit. This approach will be optional but =
not mandatory, i.e. user configurable.
Thanks,
Reshma
> Neil
>=20
> > Thanks,
> > Reshma
> >
> > > Neil
> >
> >