Hi Beilei, On Tue, Sep 12, 2017 at 06:40:50AM +0000, Xing, Beilei wrote: > Hi Adrien, > > > -----Original Message----- > > From: Adrien Mazarguil [mailto:adrien.mazarg...@6wind.com] > > Sent: Thursday, September 7, 2017 8:20 PM > > To: Xing, Beilei <beilei.x...@intel.com> > > Cc: Wu, Jingjing <jingjing...@intel.com>; Chilikin, Andrey > > <andrey.chili...@intel.com>; dev@dpdk.org > > Subject: Re: [dpdk-dev] [PATCH v2 2/6] ethdev: add GTPC and GTPU items > > > > Hi Beilei, > > > > I assume this patch supersedes [1]? > > > > [1] http://dpdk.org/ml/archives/dev/2017-August/073501.html > > > > Thanks for merging testpmd and the API change as a single patch, I still > > have > > a few comments, see below. > > > > (please add "flow API" somewhere in the title by the way) > > Thanks for all your comments. > Yes, http://dpdk.org/ml/archives/dev/2017-August/073501.html is superseded > and did merging testpmd and API change. > I will update title in next version.
All right, thanks. > > On Thu, Sep 07, 2017 at 07:20:59PM +0800, Beilei Xing wrote: > > > This patch adds GTPC and GTPU items to generic rte flow, and also > > > exposes the following item fields through the flow command: > > > > > > - GTPC TEID > > > - GTPU TEID > > > > > > Signed-off-by: Beilei Xing <beilei.x...@intel.com> > > > > Won't there be a need to match nonspecific GTP traffic as well (both GTP-C > > and GTP-U a once), since they use the same structure? > > > > I'm not familiar with the protocol at all so I wonder if you should maybe > > leave > > the GTP item in addition to those two. > > > > Agree, I will leave the GTP item in next version. > > GTP-C and GTP-U use the same structure, the difference between them is UDP > port, 2123 is for GTP-C, and 2152 is for GTP-U. > Add GTP-C and GTP -U item since I want to design a user-friendly CLI. > > For example, if user wants to add such flow: assign GTP-U packets with TEID > 0x123456 to queue 14. > Then use can use following CLI: > flow create 0 ingress pattern eth / ipv4 / udp / gtpu teid is 0x123456 / end > actions queue index 14 / end > instead of below CLI to distinguish GTP-C and GTP-U with UDP port: > flow create 0 ingress pattern eth / ipv4 / udp dst spec 2125 dst mask 0 / gtp > teid is 0x123456 / end actions queue index 14 / end I agree with you from a usability standpoint it's much nicer. I have one question though, could one send GTP-C / GTP-U traffic using nondefault UDP ports and expect hardware to match it without explicitly specifying a port in the UDP item, that is, is there some property in GTP-C / GTP-U traffic outside the UDP port that would theoretically allow a host (even a stateful one) to tell them apart? If it really depends on the UDP port only, not specifying one will use hardware defaults regardless of the item (GTP / GTP-U / GTP-C). However if like VXLAN, this default value can be modified outside of rte_flow, most users will have to specify it regardless in order to get consistent results across various vendors/adapters. In any case I don't mind three items. GTP encompasses both GTP-U and GTP-C (possibly two different UDP ports at once), while GTP-U and GTP-C match exactly one. You only have to describe this properly in the documentation. Thanks. -- Adrien Mazarguil 6WIND
