From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by dpdk.org (Postfix) with ESMTP id 85A3E7E7B for ; Fri, 17 Oct 2014 11:00:08 +0200 (CEST) Received: by mail-wg0-f43.google.com with SMTP id m15so439053wgh.14 for ; Fri, 17 Oct 2014 02:08:05 -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=00ZKlY4Ko45L69Z3ExCoIecbWal+ObfbxzlRn+wI9lQ=; b=IjrG45vk7P6f8wbcpgGJizSHBhPyvjjf9ZI5xKqnXJdldO3pk+XJjKxeaOw0tOpo3P EfyifLfyt1d40QLgyBRUMPuNCuZ3x+5UZe9W46kbtTpyeaLtEXEbx8uyWRCdmk9AYssC XpDB7wJb3I9dlG4cpPbCk4ro01xvINPoLuLFzmhNLjGM9oLpNnuCRWthrB7DL3ljVv9o fQ12zeCFdFv1DtBKBAeNB7tFQrws2q8kdMl64qfRlrtMheVtXtPLAT0cY5QQojKnwQ5o pg8kZN1Z9wXCXV3bd63daL9iQBzoF53wt8/9CVov9EG+62ZMtE3TXughQW17nkeO1EZ3 kICA== X-Gm-Message-State: ALoCoQm8CzgEg7zLwSNd8EpZviBGg+HUon+AHd/HebWOtfbAA7DUzq/qvQkyhRg7QHTRMfXTEPg0 X-Received: by 10.194.170.167 with SMTP id an7mr8708378wjc.57.1413536885612; Fri, 17 Oct 2014 02:08:05 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id yr9sm917626wjc.31.2014.10.17.02.08.04 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Oct 2014 02:08:04 -0700 (PDT) From: Thomas Monjalon To: Jingjing Wu Date: Fri, 17 Oct 2014 11:07:49 +0200 Message-ID: <4027817.y7ZgbDzL4P@xps13> Organization: 6WIND User-Agent: KMail/4.14.1 (Linux/3.16.4-1-ARCH; KDE/4.14.1; x86_64; ; ) In-Reply-To: <1413502161-31403-1-git-send-email-jingjing.wu@intel.com> References: <1413502161-31403-1-git-send-email-jingjing.wu@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] lib/librte_ether: new filter APIs definition 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, 17 Oct 2014 09:00:08 -0000 2014-10-17 07:29, Jingjing Wu: > Define new APIs to support configure multi-kind filters using same APIs, > instead of creating each API set for each kind of filter. > - rte_eth_dev_filter_supported > - rte_eth_dev_filter_ctrl > > Filter types, operations, and structures are defined specifically > in new header file lib/librte_eth/rte_dev_ctrl.h. > > As to the implementation discussion, please refer to > http://dpdk.org/ml/archives/dev/2014-September/005179.html [...] > --- /dev/null > +++ b/lib/librte_ether/rte_eth_ctrl.h Why this name? I think we can reserve this file for filtering API. So rte_eth_rx_filter.h would be more appropriate. > +/** > + * All generic operations to filters > + */ rewording: "Generic operations on filters" Could you elaborate on "generic"? What would mean "specific"? > +enum rte_filter_op { > + RTE_ETH_FILTER_OP_NONE = 0, > + /**< used to check whether the type filter is supported */ > + RTE_ETH_FILTER_OP_ADD, /**< add filter entry */ > + RTE_ETH_FILTER_OP_UPDATE, /**< update filter entry */ > + RTE_ETH_FILTER_OP_DELETE, /**< delete filter entry */ > + RTE_ETH_FILTER_OP_FLUSH, /**< flush all entries */ > + RTE_ETH_FILTER_OP_GET, /**< get filter entry */ > + RTE_ETH_FILTER_OP_SET, /**< configurations */ > + RTE_ETH_FILTER_OP_GET_INFO, Could we remove "OP", except for OP_NONE and OP_MAX? > + /**< get information of filter, such as status or statistics */ > + RTE_ETH_FILTER_OP_MAX, > +}; > +int > +rte_eth_dev_filter_supported(uint8_t port_id, enum rte_filter_type filter_type) This function is really important for compatibility. Good > +/** > + * Take operations to assigned filter type on an Ethernet device. > + * All the supported operations and filter types are defined in 'rte_eth_ctrl.h'. > + * > + * @param port_id > + * The port identifier of the Ethernet device. > + * @param filter_type > + * filter type. > + * @param filter_op > + * The operation taken to assigned filter. Rewording: "Type of operation" > + * @param arg > + * A pointer to arguments defined specifically for the operation. Actually, arg is specific to the filter type. Could it be also specific to the operation. Maybe. I think we will have to explicitly specify which operations can be used with each structure (in its comments). > + * @return > + * - (0) if successful. > + * - (-ENOTSUP) if hardware doesn't support. > + * - (-ENODEV) if *port_id* invalid. > + * - others depends on the specific operations implementation. > + */ > +int rte_eth_dev_filter_ctrl(uint8_t port_id, enum rte_filter_type filter_type, > + enum rte_filter_op filter_op, void *arg); Could we add rx in the name? rte_eth_dev_rx_filter_ctrl If you agree with this naming, it should be added in several other places. This API is quite simple (which is a good thing). Let's see how it fits when integrating filtering features. If something appears to be wrongly designed when integrating a feature or when implementing it in a driver, feel free to fix the API. Thanks -- Thomas