From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by dpdk.org (Postfix) with ESMTP id 8CAEF593E for ; Thu, 16 Oct 2014 17:59:41 +0200 (CEST) Received: by mail-wi0-f174.google.com with SMTP id h11so2154459wiw.7 for ; Thu, 16 Oct 2014 09:07:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=+zdx0DD1t25VPf1bhIcjKwsE+3ZwZ1hgYWYpad+p4m0=; b=MtKe8Br7Gs+Q6XBRrHTnHEA7Pa/PN8naoL/TnojPqjDBTVOr2ityaGqCswdNVTeGNv ZHJPLErsaK4GddErB8iuS4rAP+FBsPlGPtMqIg5UvJyU3g/62n42tooj98djg5xnmevK LI2xYnPvZ3N47/lSyj7sbWa0mqBo8bmDoM1VvKjIWDc/Fu+HbiAeiHZb4dlFpFH3V/A/ P7e04wxmT8jlJCLOD/UuwTp7tkOzKwPYqkG3620j6v6OCMv7J17YPxRQkYBpCUjshpJg BM5o2aVHDB5Ox7ZncXkrSszGdO9BQQSP7wtpZJbsxnEtnaNVAiAOXs6rd1OjF7zrsvNl 2YrQ== X-Gm-Message-State: ALoCoQl4yIgrxUX9Chm5YH3gdv0uZoy1KACFqLUQqjQB3hpuQeAcepNhHqx6JT00+jH54wemO1j3 X-Received: by 10.180.12.50 with SMTP id v18mr7307821wib.60.1413475655520; Thu, 16 Oct 2014 09:07:35 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id q5sm27903748wja.49.2014.10.16.09.07.34 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Oct 2014 09:07:34 -0700 (PDT) From: Thomas Monjalon To: "Wu, Jingjing" Date: Thu, 16 Oct 2014 18:07:18 +0200 Message-ID: <5217868.ALJSpaWAWD@xps13> Organization: 6WIND User-Agent: KMail/4.14.1 (Linux/3.16.4-1-ARCH; KDE/4.14.1; x86_64; ; ) In-Reply-To: <9BB6961774997848B5B42BEC655768F8ADFFBD@SHSMSX104.ccr.corp.intel.com> References: <9BB6961774997848B5B42BEC655768F8ADE579@SHSMSX104.ccr.corp.intel.com> <9BB6961774997848B5B42BEC655768F8ADFFBD@SHSMSX104.ccr.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] filter_ctl PMD API idea 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, 16 Oct 2014 15:59:41 -0000 2014-09-08 15:06, Wu, Jingjing: > Any comments or advises?=20 >=20 > Thanks! >=20 > Fortville Filter features' development will be started based on this = design this week. Thanks Jingjing for explaining your plan before working on it. There were no comment for 1 month so we'll assume everybody is OK. Now your work is done and it's time to integrate it. This design is used in many pending patchsets. Now I wait for an unique patch out of any patchset in order to do some comments about implementation. Then it will be applied with i40e filters using this API. So we'll have a new API implemented only for i40e. But when DPDK 1.8 will be out, I expect to receive patches replacing ol= d API with this new one for igb and ixgbe. Last request, please could you write a brief email summarizing all filt= ers of Intel NICs from an user perspective, and which ones are implemented = in DPDK, with which API? Thanks > > -----Original Message----- > > Hi, all > >=20 > > When we develop filters feature in i40e driver for Intel=C2=AE Ethe= rnet Controller XL710/X710 > > [Fortville] (For both 10G/40G), we found that there are lots of new= filters, there are also > > some changes on the existing filters, comparing to ixgbe. > > If we keep the way to add new ops in rte_eth_dev for each new filte= r, it can work. > > But we suggest to use a more generic API for all filters to avoid a= superset dev_ops. It needs > > to be cleaner and easy-to-use. There is a need for technical discus= sion. > >=20 > > Here is the early design idea we are looking for comments. > >=20 > > 1. Create two new APIs > > ----------------------------------------------------- > > rte_eth_filter_supported(uint8_t port, uint16_t filter_type); > > /* check whether this filter type is supported for the queried port= */ > > rte_eth_filter_ctl(uint8_t port, uint16_t filter_type, uint16_t fil= ter_op, void *arg); > > /* configure filters, will call new ops eth_filter_ctl in eth_dev_o= ps */ > > ----------------------------------------------------- > >=20 > > 2. Define filter types, operations, and structures in new header = file > > lib/librte_eth/rte_eth_filter.h. > > ----------------------------------------------------- > > #define RTE_ETH_FILTER_RSS=09=091 > > #define RTE_ETH_FILTER_SYN=09 2 > > #define RTE_ETH_FILTER_5TUPLE=09 3 > > #define RTE_ETH_FILTER_FDIR=09=094 > > .... > >=20 > > #define RTE_ETH_FILTER_OP_GET =091 > > #define RTE_ETH_FILTER_OP_ADD =092 > > #define RTE_ETH_FILTER_OP_DELETE=09=093 > > #define RTE_ETH_FILTER_OP_SET=09=09=094 > > ....< other operations if want to define>... > >=20 > > /* structures defined for corresponding filter type and operation *= / > > /* take RTE_ETH_FILTER_FDIR and OP_SET for example*/ > >=20 > > struct rte_eth_filter_fdir_cfg { > > #define RTE_ETH_FILTER_FDIR_SET_MASK 0 > > #define RTE_ETH_FILTER_FDIR_SET_OFFSET 1 > > =E2=80=A6=E2=80=A6 > > =09uint16_t cfg_type; > > =E3=80=80=E3=80=80/* sub operation to defined what specific configu= ration it will take, > > =E3=80=80=E3=80=80=E3=80=80and which following fields are meaningfu= l*/ > > =E3=80=80=E3=80=80=E2=80=A6=E2=80=A6 > > =E3=80=80=E3=80=80/* fields, can be a union or combine of required = specific items*/ > > =E3=80=80=E3=80=80=E2=80=A6=E2=80=A6 > >=20 > > }; > >=20 > > ----------------------------------------------------- > > By this way, It is easy to add more filter types or operation in fu= ture. > > And the difference among the same filter and operation can be disti= nguish by sub command > > in defined structure, e.g. =E2=80=9Dcfg_type=E2=80=9D in above rte_= eth_filter_fdir_cfg structure. > >=20 > > 3. Define ops in driver (take i40e for example) > > ----------------------------------------------------- > > static struct eth_dev_ops i40e_eth_dev_ops =3D { > > . filter_ctl =3D i40e_filter_ctl, > > }; > > ----------------------------------------------------- > > Then the functions in drivers can be implemented separately. > >=20 > > 4. Use case In test-pmd/cmdline.c > > ----------------------------------------------------- > > #include > > /* add or change commands e.g. fdir_set (arg1) (arg2) =E2=80=A6=E2=80= =A6 */ > >=20 > > static void > > cmd_fdir_parsed() > > { > > =09=E2=80=A6=E2=80=A6 > > =E3=80=80=E3=80=80/* take setting fdir mask for example*/ > > =E3=80=80=E3=80=80struct rte_eth_filter_fdir_cfg cfg; > >=20 > > =E3=80=80=E3=80=80if (rte_eth_filter_supported(port, RTE_ETH_FILTER= _FDIR)) { > > =E3=80=80=E3=80=80=09cfg.cfg_type =3D RTE_ETH_FILTER_FDIR_SET_MASK;= > > =E3=80=80=E3=80=80=09/* fill the corresponding fields in cfg*/ > > =E3=80=80=E3=80=80=09=E2=80=A6=E2=80=A6 > > =E3=80=80=E3=80=80=09rte_eth_filter_ctl(port, RTE_ETH_FILTER_FDIR, = RTE_ETH_FILTER_OP_SET, &cfg); > > =E3=80=80=E3=80=80} > > =09=E2=80=A6=E2=80=A6 > > } > > ----------------------------------------------------- > >=20 > >=20 > > Any comments are welcome! > >=20 > > At the time being, only Intel PMD is only available on dpdk.org. We= are lack of understanding > > on the other non-Intel PMD, the current design did not take them in= to account. But we are > > looking for the inputs from those PMD developers, we strongly look = forward to those PMD > > are released as open source. > >=20 > > Thanks! > > Jingjing