From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id DC826677B for ; Fri, 31 Oct 2014 07:59:41 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 31 Oct 2014 00:08:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,293,1413270000"; d="scan'208";a="623973313" Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82]) by fmsmga002.fm.intel.com with ESMTP; 31 Oct 2014 00:08:24 -0700 Received: from pgsmsx106.gar.corp.intel.com (10.221.44.98) by PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 31 Oct 2014 15:05:40 +0800 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by pgsmsx106.gar.corp.intel.com (10.221.44.98) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 31 Oct 2014 15:05:39 +0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.174]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.202]) with mapi id 14.03.0195.001; Fri, 31 Oct 2014 15:05:38 +0800 From: "Wu, Jingjing" To: Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH v2 1/3] ethdev: define ctrl_pkt filter type and its structure Thread-Index: AQHP7dEkLbxhXZVk7kqrDLbF9UwYj5xIxSIAgAD9qxA= Date: Fri, 31 Oct 2014 07:05:38 +0000 Message-ID: <9BB6961774997848B5B42BEC655768F8B26609@SHSMSX104.ccr.corp.intel.com> References: <1411628369-29532-1-git-send-email-jingjing.wu@intel.com> <1413965977-15165-1-git-send-email-jingjing.wu@intel.com> <1413965977-15165-2-git-send-email-jingjing.wu@intel.com> <1607705.DDyl0z8Nv8@xps13> In-Reply-To: <1607705.DDyl0z8Nv8@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] 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 v2 1/3] ethdev: define ctrl_pkt filter type and its structure 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: Fri, 31 Oct 2014 06:59:42 -0000 Hi, Thomas Thanks for your comments Jingjing=20 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Friday, October 31, 2014 6:47 AM > To: Wu, Jingjing > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2 1/3] ethdev: define ctrl_pkt filter typ= e > and its structure >=20 > 2014-10-22 16:19, Jingjing Wu: > > +/** > > + * Define all structures for Control Packet Filter type corresponding = with > specific operations. > > + */ >=20 > Please explain what is a control packet. A control element in Fortville can be used to receive control packets and c= ontrol other switching elements. Control packet filter can filter control p= acket (such as LLDP) to different queues in receive and identify the switch= element that should process the packets in transmit. At the same time, we also can use this filter to route non-control packets = to queue or other engine by filtering mac and ether_type. The name "control= packet filter" comes from Fortville. >=20 > > + > > +#define RTE_CONTROL_PACKET_FLAGS_IGNORE_MAC 0x0001 > > +#define RTE_CONTROL_PACKET_FLAGS_DROP 0x0002 > > +#define RTE_CONTROL_PACKET_FLAGS_TO_QUEUE 0x0004 > > +#define RTE_CONTROL_PACKET_FLAGS_TX 0x0008 > > +#define RTE_CONTROL_PACKET_FLAGS_RX 0x0000 >=20 > Flag RX is 0? Yes, RX is default value. Maybe it need to be removed.=20 >=20 > > +/** > > + * A structure used to define the control packet filter entry > > + * to support RTE_ETH_FILTER_CTRL_PKT with RTE_ETH_FILTER_ADD > > + * and RTE_ETH_FILTER_DELETE operations. > > + */ > > +struct rte_ctrl_pkt_filter { > > + struct ether_addr mac_addr; /**< mac address to match. */ > > + uint16_t ether_type; /**< ether type to match */ > > + uint16_t flags; /**< options for filter's behavior*/ > > + uint16_t dest_id; /**< destination vsi id or pool id*/ >=20 > vsi id and pool id cannot be understood in a generic context. > Please explain what you mean and why queue is not enough. If queue is not specified, dest_id defines which element (vsi) will get the= packet. If queue is specified, the queue need belong to the destination element. >=20 > > + uint16_t queue; /**< queue assign to if TO QUEUE flag i= s set > */ >=20 > TO QUEUE is not defined. Is it really needed? >=20 TO QUEUE is just the flag RTE_CONTROL_PACKET_FLAGS_TO_QUEUE above. > Thanks > -- > Thomas