From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) by dpdk.org (Postfix) with ESMTP id 7C7BC1B1B0 for ; Thu, 5 Oct 2017 10:30:31 +0200 (CEST) Received: by mail-wm0-f48.google.com with SMTP id 196so855292wma.1 for ; Thu, 05 Oct 2017 01:30:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=j4IfQRckwJw8qfc7KFZEOboaRcoZ0EUp+IeL/prFWcY=; b=w9DFwPWS6KxBYPBNxP0IGPflr6nOy8hIqDFMJWnVWdHghM/pcFi29LJGg7/hV8GSlH /8kXOGbmjssMywdVBITcQ6W/RfUVm/jLkUycZHWPJKW7wjH+Pn2RWcHmk4g3sTfiIHnr 6IotqTKJ3UrjpYCg6XWOH9qsFoCf8cS97rZtmxdostpVGAj1Tu3FsWR3UKX8IrvHHYlg siVRM9ymSKe9gPnWO1Wy2yeK0NAuNbx29MbnUZUaU6OIb4o0xnpDCCYZotYOSmgomRGI xKc6eTpiIK7kNFcj6M9t+x+OMN8+mNTuiZamJP5qelEV1uqoauiNsbB9rZ2zxYmsuHd5 uRAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=j4IfQRckwJw8qfc7KFZEOboaRcoZ0EUp+IeL/prFWcY=; b=aB1auRkehSu7inFsDMWfZ3E8En0H/5aRJEbwIpqsvUFnM8O+iQJ9Qju/Cx4QzwaNwy Twn1O7nT+iiK43YK1BJsRE0QenYmF44lo+A3Ezhbsbz/uXWhOJpkv137L/8k6Rqbsadv kpFtKCwFRaJB2AKzpJTTkMAAGJqYahcNjdXamklaw6la43cJsXFEAPUOVNXfi/J3pe9a evOT5B+arepa0VjaTsp25Oh6N3W0Sgt4TZBed/FlDoitIAm8fN+tJtjZphoBV/gUfUwI IcNLmBZtT9h2fQwglZz1GJZOyAM/0CFqShyE9cwCVitvCMLlGKmQXCklwwvow3ESuUiW Jfvw== X-Gm-Message-State: AHPjjUhPVLTwg3mHTx0z8LAGea1I/mqCAhdw4fLRXjbVQqqWmbN1F+Gy ptIkv85PdhK0dWiuT+Y7Pt6BWMor X-Google-Smtp-Source: AOwi7QDYql6LgdBTPYLAK5zMaU+sQZOaoUybFHuKZ0eSkjV14eIIoEw7kC/KBaK1WzqdfufNe5f/xw== X-Received: by 10.80.168.33 with SMTP id j30mr31448859edc.64.1507192231216; Thu, 05 Oct 2017 01:30:31 -0700 (PDT) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id c34sm15513556ede.84.2017.10.05.01.30.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Oct 2017 01:30:30 -0700 (PDT) Date: Thu, 5 Oct 2017 10:30:19 +0200 From: Adrien Mazarguil To: "Wu, Jingjing" Cc: Sean Harte , "Xing, Beilei" , "Chilikin, Andrey" , "dev@dpdk.org" Message-ID: <20171005083019.GY3871@6wind.com> References: <1506565054-67690-1-git-send-email-beilei.xing@intel.com> <1506662342-18966-1-git-send-email-beilei.xing@intel.com> <1506662342-18966-5-git-send-email-beilei.xing@intel.com> <94479800C636CB44BD422CB454846E0132038E26@SHSMSX101.ccr.corp.intel.com> <20171002122737.GK3871@6wind.com> <9BB6961774997848B5B42BEC655768F810E89F3C@SHSMSX103.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9BB6961774997848B5B42BEC655768F810E89F3C@SHSMSX103.ccr.corp.intel.com> Subject: Re: [dpdk-dev] [PATCH v6 4/8] ethdev: add GTP items to support flow API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 08:30:31 -0000 On Thu, Oct 05, 2017 at 08:06:38AM +0000, Wu, Jingjing wrote: > > > > -----Original Message----- > > From: Sean Harte [mailto:seanbh@gmail.com] > > Sent: Tuesday, October 3, 2017 4:57 PM > > To: Adrien Mazarguil > > Cc: Xing, Beilei ; Wu, Jingjing ; Chilikin, > > Andrey ; dev@dpdk.org > > Subject: Re: [dpdk-dev] [PATCH v6 4/8] ethdev: add GTP items to support flow API > > > > On 2 October 2017 at 13:27, Adrien Mazarguil wrote: > > > On Fri, Sep 29, 2017 at 10:29:55AM +0100, Sean Harte wrote: > > >> On 29 September 2017 at 09:54, Xing, Beilei wrote: > > > > > >> >> > /** > > >> >> > + * RTE_FLOW_ITEM_TYPE_GTP. > > >> >> > + * > > >> >> > + * Matches a GTPv1 header. > > >> >> > + */ > > >> >> > +struct rte_flow_item_gtp { > > >> >> > + /** > > >> >> > + * Version (3b), protocol type (1b), reserved (1b), > > >> >> > + * Extension header flag (1b), > > >> >> > + * Sequence number flag (1b), > > >> >> > + * N-PDU number flag (1b). > > >> >> > + */ > > >> >> > + uint8_t v_pt_rsv_flags; > > >> >> > + uint8_t msg_type; /**< Message type. */ > > >> >> > + rte_be16_t msg_len; /**< Message length. */ > > >> >> > + rte_be32_t teid; /**< Tunnel endpoint identifier. */ }; > > >> >> > > >> >> In future, you might add support for GTPv2 (which is used since LTE). > > >> >> Maybe this structure should have v1 in its name to avoid confusion? > > >> > > > >> > I considered it before. But I think we can modify it when we support GTPv2 in future, > > and keep concise 'GTP' currently:) since I have described it matches v1 header. > > >> > > > >> > > >> You could rename v_pt_rsv_flags to version_flags to avoid some future > > >> code changes to support GTPv2. There's still the issue that not all > > >> GTPv2 messages have a TEID though. > > > > > > Although they have the same size, the header of these two protocols > > > obviously differs. My suggestion would be to go with a separate GTPv2 > > > pattern item using its own dedicated structure instead. > > > > > > -- > > > Adrien Mazarguil > > > 6WIND > > > > The 1st four bytes are the same (flags in first byte have different > > meanings, but the bits indicating the version are in the same > > location). After that, different fields in each version are optional, > > and the headers have variable size. A single structure could be used > > if the first field is renamed to something like "version_flags", and > > then check that the teid field in item->mask is not set if > > ((version_flags >> 5 == 2) && ((version_flags >> 4) & 1) == 1). If > > there's going to be two structures, it would be good to put v1 and v2 > > in the names, in my opinion. > > I think the name GTP is OK for now. Due to v1 and v2 are different, why not rename them > when the v2 supporting are introduced? In any case I'd rather avoid renaming and modifying existing items and structure contents once part of the API to avoid API/ABI breakage that require deprecation notices, user applications updates and so on; rte_flow has been created as a kind of append-only API for this reason (of course there are exceptions, such as a bad design choice for the VLAN item I intend to fix at some point). I'm fine with the name "GTP" as defined now and documented as matching GTPv1. We can add "GTPv2"-themed definitions later when some implementation provides the ability to match this version. If you want to append the "v1" suffix right now to be more explicit, I'm also fine with that. Your call. -- Adrien Mazarguil 6WIND