From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yh0-f51.google.com (mail-yh0-f51.google.com [209.85.213.51]) by dpdk.org (Postfix) with ESMTP id ED5E37EF7 for ; Thu, 9 Oct 2014 20:54:34 +0200 (CEST) Received: by mail-yh0-f51.google.com with SMTP id t59so1054020yho.10 for ; Thu, 09 Oct 2014 12:01:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1HPSdNm+/2XyKscrQTlTaCqtmzcBV5a4r5vsU4m62U8=; b=dNaS79ecvp/p4XW/D0FKnvsmxq47ACjsz74K9nsm7yx0c+USc+JID24AQW18MFO93A ld4mrSHRUqlyfqlRnUH6S+P5/MAt+jh+16hFv1R9MRInVfKcHUEbIxYCYAgRwEY1nIJu GDmpdPDfChfzN8RFmkwMC+IDW3pQ+mDBSQwVrqq+5XDvicJgvdTpdHjbf2ReMOdo15pY ZD3zdQmTK8sQpAD1AL7kHAolZK/ylb/SnKZSPJP8oLRkcyM/fK2U9n34uBr3i/12N/qu Jl+nZinZYoCSVwwrunOjJ7y6nTlpDc9/j3gcpXGG6jcalXuFU5ZDcFqesMypUBPPl4qi o2Xw== X-Gm-Message-State: ALoCoQkBMSv1wC+zUYnm6+CvNezO04RrMZCXhtKbeRPxscG45stKK/Oru8kkSL678gvnm8nwv/J2 MIME-Version: 1.0 X-Received: by 10.236.96.232 with SMTP id r68mr232160yhf.56.1412881314880; Thu, 09 Oct 2014 12:01:54 -0700 (PDT) Received: by 10.170.84.10 with HTTP; Thu, 9 Oct 2014 12:01:54 -0700 (PDT) In-Reply-To: <3AEA2BF9852C6F48A459DA490692831FE21954@IRSMSX109.ger.corp.intel.com> References: <3AEA2BF9852C6F48A459DA490692831FE21954@IRSMSX109.ger.corp.intel.com> Date: Thu, 9 Oct 2014 14:01:54 -0500 Message-ID: From: Jay Rolette To: "Pattan, Reshma" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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 18:54:35 -0000 Hi Reshma, A few comments and questions about your design... 1) How do you envision the reorder library to be used? Based on the description, it seems like the expectation is that packet order would be maintained at either the interface/port level or maybe at the RX queue level. Is that right or am I reading too much between the lines? For my purposes (and for network security products I've developed in the past), I mostly don't care about box or port-level order. The most important thing is to maintain packet order within a flow. Relative order from packets in different flows doesn't matter. If there is a way I can process packets in parallel and transmit out-of-order transmission *within the flow*, that's very useful. Architecturally, it helps avoid hot-spotting in my packet processing pipeline and wasting cycles when load-balancing isn't perfect (and it never is). 2) If the reorder library is "flow aware", then give me flexibility on deciding what a flow is. Let me define pseudo-flows even if the protocol itself isn't connection oriented (ie., frequently useful to treat UDP 5-tuples as a flow). I may want to include tunnels/VLANs/etc. as part of my "flow" definition. I may need to include the physical port as part of the flow definition. Ideally, the library includes the common cases and gives me the option to register a callback function for doing whatever sort of "flows" I require for my app. 3) Is there a way to apply the reorder library to some packets and not others? I might want to use for TCP and UDP, but not care about order for other IP traffic (for example). 4) How are you dealing with internal congestion? If I drop a packet somewhere in my processing pipeline, how does the TX side of the reorder queue/buffer deal with the missing sequence number? Is there some sort of timeout mechanism so that it will only wait for X microseconds for a missing sequence number? Need the ability to bound how long packets are held up in the reorder engine before they are released. Assuming you address this, the reorder engine will also need to deal with slow packets that show up after "later" packets were transmitted. Regards, Jay On Tue, Oct 7, 2014 at 4:33 AM, 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 buffer */ > unsigned int head; /* Current head of buffer */ > uint32_t min_seqn; /* latest sequence number associated 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 > > -------------------------------------------------------------- > Intel Shannon Limited > Registered in Ireland > Registered Office: Collinstown Industrial Park, Leixlip, County Kildare > Registered Number: 308263 > Business address: Dromore House, East Park, Shannon, Co. Clare > > This e-mail and any attachments may contain confidential material for the > sole use of the intended recipient(s). Any review or distribution by others > is strictly prohibited. If you are not the intended recipient, please > contact the sender and delete all copies. > >