From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by dpdk.org (Postfix) with ESMTP id 97ACA5684 for ; Fri, 9 Jan 2015 15:01:50 +0100 (CET) Received: by mail-wi0-f179.google.com with SMTP id ex7so2499475wid.0 for ; Fri, 09 Jan 2015 06:01:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=H8xwWA9kbjrpkFUWnQEfsQPUxZPqpNW1MsnrhQzUGnU=; b=a/ZsUcGU/TWf2XbXN6xCLoAeV2UED6gvDyr/FzOCSoiPTEatMwuaoEi9W2HO9T6NKL EHrNXRR+r97v9Cgf6OwqvjGJfqXeyPn0/ZzcAtFUVZYxWjLca/FclKawRJuIJyFiQh7A cr18jHt/iYFqPi6U3hGoedCMzYzq9Gqfp1gG7q3WtHefH3gz33qPwV6FKEkAc90PtdHd 0gB8OtEEjG3pKIE0ouyvObzmX+r8ZvY9/IkGPT2tYEKyZBx1cNfaTL1m5o9X+PBbJrJP TMSnxc9NsYCzv7ni+YvDUtqDXxVfa4l6geeclEuYcaSgThTMBPFSez0Moy1kXoZc3nLF i/Zw== X-Gm-Message-State: ALoCoQk5aExAYl59uGg5602gZhlLy5v/whNTToN1LtSeaXG7Yy2w3s+v31NmwAY2mcO1qNLkTdt2 X-Received: by 10.180.76.144 with SMTP id k16mr5286691wiw.3.1420812108941; Fri, 09 Jan 2015 06:01:48 -0800 (PST) Received: from [10.0.0.4] ([109.66.137.113]) by mx.google.com with ESMTPSA id js5sm25846000wid.11.2015.01.09.06.01.48 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Jan 2015 06:01:48 -0800 (PST) Message-ID: <54AFDF4B.2070803@cloudius-systems.com> Date: Fri, 09 Jan 2015 16:01:47 +0200 From: Vlad Zolotarov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Ouyang, Changchun" , "dev@dpdk.org" References: <1420355937-18484-1-git-send-email-changchun.ouyang@intel.com> <1420612355-6666-1-git-send-email-changchun.ouyang@intel.com> <1420612355-6666-6-git-send-email-changchun.ouyang@intel.com> <54AE5134.3070808@cloudius-systems.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v5 5/6] ixgbe: Config VF RSS 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, 09 Jan 2015 14:01:50 -0000 On 01/09/15 08:07, Ouyang, Changchun wrote: > >> -----Original Message----- >> From: Vlad Zolotarov [mailto:vladz@cloudius-systems.com] >> Sent: Thursday, January 8, 2015 5:43 PM >> To: Ouyang, Changchun; dev@dpdk.org >> Subject: Re: [dpdk-dev] [PATCH v5 5/6] ixgbe: Config VF RSS >> >> >> On 01/07/15 08:32, Ouyang Changchun wrote: >>> It needs config RSS and IXGBE_MRQC and IXGBE_VFPSRTYPE to enable VF >> RSS. >>> The psrtype will determine how many queues the received packets will >>> distribute to, and the value of psrtype should depends on both facet: >>> max VF rxq number which has been negotiated with PF, and the number of >> rxq specified in config on guest. >>> Signed-off-by: Changchun Ouyang >>> >>> Changes in v4: >>> - the number of rxq from config should be power of 2 and should not >> bigger than >>> max VF rxq number(negotiated between guest and host). >>> >>> --- >>> lib/librte_pmd_ixgbe/ixgbe_pf.c | 15 ++++++ >>> lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 103 >> +++++++++++++++++++++++++++++++++----- >>> 2 files changed, 106 insertions(+), 12 deletions(-) >>> >>> diff --git a/lib/librte_pmd_ixgbe/ixgbe_pf.c >>> b/lib/librte_pmd_ixgbe/ixgbe_pf.c index dbda9b5..93f6e43 100644 >>> --- a/lib/librte_pmd_ixgbe/ixgbe_pf.c >>> +++ b/lib/librte_pmd_ixgbe/ixgbe_pf.c >>> @@ -187,6 +187,21 @@ int ixgbe_pf_host_configure(struct rte_eth_dev >> *eth_dev) >>> IXGBE_WRITE_REG(hw, IXGBE_MPSAR_LO(hw- >>> mac.num_rar_entries), 0); >>> IXGBE_WRITE_REG(hw, IXGBE_MPSAR_HI(hw- >>> mac.num_rar_entries), 0); >>> >>> + /* >>> + * VF RSS can support at most 4 queues for each VF, even if >>> + * 8 queues are available for each VF, it need refine to 4 >>> + * queues here due to this limitation, otherwise no queue >>> + * will receive any packet even RSS is enabled. >>> + */ >>> + if (eth_dev->data->dev_conf.rxmode.mq_mode == >> ETH_MQ_RX_VMDQ_RSS) { >>> + if (RTE_ETH_DEV_SRIOV(eth_dev).nb_q_per_pool == 8) { >>> + RTE_ETH_DEV_SRIOV(eth_dev).active = >> ETH_32_POOLS; >>> + RTE_ETH_DEV_SRIOV(eth_dev).nb_q_per_pool = 4; >>> + RTE_ETH_DEV_SRIOV(eth_dev).def_pool_q_idx = >>> + dev_num_vf(eth_dev) * 4; >>> + } >>> + } >>> + >>> /* set VMDq map to default PF pool */ >>> hw->mac.ops.set_vmdq(hw, 0, >>> RTE_ETH_DEV_SRIOV(eth_dev).def_vmdq_idx); >>> >>> diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c >>> b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c >>> index f69abda..e83a9ab 100644 >>> --- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c >>> +++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c >>> @@ -3327,6 +3327,68 @@ ixgbe_alloc_rx_queue_mbufs(struct >> igb_rx_queue *rxq) >>> } >>> >>> static int >>> +ixgbe_config_vf_rss(struct rte_eth_dev *dev) { >>> + struct ixgbe_hw *hw; >>> + uint32_t mrqc; >>> + >>> + ixgbe_rss_configure(dev); >>> + >>> + hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private); >>> + >>> + /* MRQC: enable VF RSS */ >>> + mrqc = IXGBE_READ_REG(hw, IXGBE_MRQC); >>> + mrqc &= ~IXGBE_MRQC_MRQE_MASK; >>> + switch (RTE_ETH_DEV_SRIOV(dev).active) { >>> + case ETH_64_POOLS: >>> + mrqc |= IXGBE_MRQC_VMDQRSS64EN; >>> + break; >>> + >>> + case ETH_32_POOLS: >>> + case ETH_16_POOLS: >> Isn't ETH_16_POOLS mode is invalid for VF RSS? It's what both spec states >> and what u handle in this patch in ixgbe_pf_host_configure(). >> IMHO it would be better to treat this mode value as an error here since if u >> get it here it indicates of a SW bug. > I think we discussed it before already, return err here will break here in the case of max vf number is less than 16. > If doing that, This make the library seems can't support vf rss in the case of max vf num less than 16. > So we obviously don't hope it break here. I don't remember we were discussing these specific lines. However I do remember we talked about the previous section of this patch. I'm afraid u are missing my point here: ixgbe_pf_host_configure() is called before ixgbe_config_vf_rss() in the ixgbe_dev_start() flow. This means that RTE_ETH_DEV_SRIOV(dev).active will already be adjusted by your (!!!) code in the ixgbe_pf_host_configure() when u get to ixgbe_config_vf_rss() and it should not be equal ETH_16_POOLS unless there is a bug in your code. So, unless I've missed something here, don't u think an assert() would be appropriate if RTE_ETH_DEV_SRIOV(dev).active equals ETH_16_POOLS? thanks, vlad > >