From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 7BDD1A0A03; Tue, 19 Jan 2021 08:49:33 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5C0E7140D06; Tue, 19 Jan 2021 08:49:33 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 04DC7140CEC for ; Tue, 19 Jan 2021 08:49:30 +0100 (CET) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id B4D2E7F5A1; Tue, 19 Jan 2021 10:49:29 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru B4D2E7F5A1 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1611042569; bh=ZsWENCj5VkSkm2NrMA5IBAEzP9Iy+N34sidOXdncA1o=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=xjZdyJk+FXKqx0hUFRnWR2W8j2SDnIXbXNuE0mskL7PMsvUOY9GNUg2NVpnm3vHmk g7gmE2x8ubjRxhHUoad/IwmnQ/S52/5HA+Mj+BR/deaDLtWqoXlKdYg16gr4ospEu3 20W/V9Fh+rN0kK9OckGof3fkDAXjqOtP8AHbXNsA= To: "Xueming(Steven) Li" , NBU-Contact-Thomas Monjalon , Ferruh Yigit , Olivier Matz Cc: "dev@dpdk.org" , Slava Ovsiienko , Asaf Penso References: <1610968623-31345-1-git-send-email-xuemingl@nvidia.com> <1610968623-31345-2-git-send-email-xuemingl@nvidia.com> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <1df19d3b-8bef-55a5-a403-7f5096a2706f@oktetlabs.ru> Date: Tue, 19 Jan 2021 10:49:29 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v4 1/9] ethdev: introduce representor type X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 1/19/21 10:37 AM, Xueming(Steven) Li wrote: > Hi Andrew, > >> -----Original Message----- >> From: Andrew Rybchenko >> Sent: Tuesday, January 19, 2021 3:25 PM >> To: Xueming(Steven) Li ; NBU-Contact-Thomas >> Monjalon ; Ferruh Yigit ; >> Olivier Matz >> Cc: dev@dpdk.org; Slava Ovsiienko ; Asaf Penso >> >> Subject: Re: [PATCH v4 1/9] ethdev: introduce representor type >> >> On 1/18/21 2:16 PM, Xueming Li wrote: >>> To support more representor type, this patch introduces representor >>> type enum. The enum is subject to extend for new types upcoming. >>> >>> Signed-off-by: Xueming Li >>> Acked-by: Viacheslav Ovsiienko >> >> One nit below and a question below. >> >> In any case: >> >> Acked-by: Andrew Rybchenko >> >> [snip] >> >>> diff --git a/lib/librte_ethdev/rte_ethdev_driver.h >>> b/lib/librte_ethdev/rte_ethdev_driver.h >>> index 0eacfd8425..3bc5c5bbbb 100644 >>> --- a/lib/librte_ethdev/rte_ethdev_driver.h >>> +++ b/lib/librte_ethdev/rte_ethdev_driver.h >>> @@ -1193,6 +1193,14 @@ __rte_internal >>> int >>> rte_eth_switch_domain_free(uint16_t domain_id); >>> >>> +/** Ethernet device representor type */ enum rte_eth_representor_type >>> +{ >>> + RTE_ETH_REPRESENTOR_NONE, /**< not a representor. */ >>> + RTE_ETH_REPRESENTOR_VF, /**< representor of VF. */ >>> + RTE_ETH_REPRESENTOR_SF, /**< representor of SF. */ >>> + RTE_ETH_REPRESENTOR_PF, /**< representor of host PF. */ >> >> RTE_ETH_REPRESENTOR_SF and PF looks dead in the patch. >> IMHO, addition of these members here make future patches which add >> support inconsistent. > > Yes, later patch in this patchset will support it. I know. The question is why it is not added in the later patches when these types are actually supported. >> >>> +}; >>> + >>> /** Generic Ethernet device arguments */ struct rte_eth_devargs { >>> uint16_t ports[RTE_MAX_ETHPORTS]; >>> @@ -1203,6 +1211,7 @@ struct rte_eth_devargs { >>> /** representor port/s identifier to enable on device */ >>> uint16_t nb_representor_ports; >>> /** number of ports in representor port field */ >>> + enum rte_eth_representor_type type; /* type of representor */ >> >> Is it intended and documented limitation that we can't add different type >> representors in one request? Or am I missing something and it is possible? > > Correct, current devargs structure can't support mix of different types. > I'll update in next version if any. >> >>> }; >>> >>> /** >>> >