From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from compass.polito.it (compass.polito.it [130.192.55.110]) by dpdk.org (Postfix) with ESMTP id D99842BC3 for ; Mon, 13 Jun 2016 13:56:48 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by compass.polito.it (Postfix) with ESMTP id 8C6C5100112 for ; Mon, 13 Jun 2016 13:56:48 +0200 (CEST) Authentication-Results: compass.polito.it (amavisd-new); dkim=pass (1024-bit key) reason="pass (just generated, assumed good)" header.d=studenti.polito.it DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= studenti.polito.it; h=content-type:content-type:cc:to:subject :subject:message-id:date:date:from:from:references:in-reply-to :received:mime-version:received:received:received; s=y2k10; t= 1465819006; bh=DSJ6n3NKJMXuZh/23/qIL8UA64s5+HtyzJaP5+rizZ0=; b=Z WjvGnC9uDQDiTIgtRJNzlOrRM/Un/JZnlkDOOuH7btLDAMianNVAU/FzUNUzgfyD ugreaFWsalkz26OVjtHgKLET2IVugqNzDmK281gY4sOWty8GAMCIn4DGSZGe0MOn mZcNPInya3c6uLpCCvuKC07sXwsZuZQXQkFNYjLGyM= X-Virus-Scanned: amavisd-new at studenti.polito.it X-Spam-Flag: NO X-Spam-Score: -5.925 X-Spam-Level: X-Spam-Status: No, score=-5.925 tagged_above=-100 required=3.5 tests=[ALL_TRUSTED=-5, AWL=0.574, BAYES_00=-1.5, HTML_MESSAGE=0.001] autolearn=ham Received: from compass.polito.it ([127.0.0.1]) by localhost (compass.polito.it [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id AXOc8sna3P5R for ; Mon, 13 Jun 2016 13:56:46 +0200 (CEST) Received: from mail-lf0-f50.google.com (mail-lf0-f50.google.com [209.85.215.50]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: s203403@studenti.polito.it) by compass.polito.it (Postfix) with ESMTPSA id 6F1051000EF for ; Mon, 13 Jun 2016 13:56:46 +0200 (CEST) Received: by mail-lf0-f50.google.com with SMTP id f6so61957107lfg.0 for ; Mon, 13 Jun 2016 04:56:46 -0700 (PDT) X-Gm-Message-State: ALyK8tJxkENUdzPz8AJZwqbZAaCcAJuOxKSYEHl4mrs8L7B2zj1MefVsbvntPOKgJck+MrF/vRXGPyJSpW8oPA== X-Received: by 10.25.23.72 with SMTP id n69mr233110lfi.64.1465819005891; Mon, 13 Jun 2016 04:56:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.89.75 with HTTP; Mon, 13 Jun 2016 04:56:45 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Mauricio_V=C3=A1squez?= Date: Mon, 13 Jun 2016 13:56:45 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Alexander Duyck Cc: dev@dpdk.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] queue to VF assigment in SR-IOV 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: Mon, 13 Jun 2016 11:56:49 -0000 Hello Alexander, On Tue, Jun 7, 2016 at 11:31 PM, Alexander Duyck wrote: > On Tue, Jun 7, 2016 at 1:49 PM, Mauricio V=C3=A1squez > wrote: > > Dear All, > > > > I implemented a program that uses flow director to forward packets to a > > specific virtual function, however I faced the problem that I did not > know > > which queue belongs to a VF. I found in [1] that in the case of Intel > > 82599, queues 0-7 belongs to VF0, 8-15 to VF1 and so on, I tested it bu= t > it > > did not work, using the trial and error method I found that queue 0 is = in > > VF0, queue 4 in VF1 and so on. > > > > My question is: is there a standard way to know which queues belong to = a > > specific VF? > > > > Thanks in advance > > > > Mauricio V, > > > > [1] > > > http://www.intel.it/content/dam/www/public/us/en/documents/datasheets/825= 99-10-gbe-controller-datasheet.pdf > , > > Table 7-72 > > If you are using the kernel driver the way the queues are laid out > depends on the number of VFs allocated and what features are enabled > in the kernel. I forgot to mention that I am using the DPDK ixgbe PMD. > Assuming you are not using DCB you should be able to > figure out how many queues are being allocated via VF by looking at > the output of "ethtool -l ". The upper limit on RSS is t he > number of queues each pool is allocated. > > So for example if you only enable up to 31 VFs then the PF driver > allocates 4 queues per VF so you would have queues 0 - 3 allocated to > VF0, queues 4-7 allocated to VF1, etc all the way through to the PF > occupying (num_vfs * 4) to 127. If you enable 32 or more VFs then the > number of queues drops to 2 per VF and RSS on the PF will be limited > to the 2 queues following the block reserved for the VFs. > > I found that the behavior of the DPDK PMD is almost the same you described: 1 - 15 VFs -> 8 queues per VF 16 - 31 VFs -> 4 queues per VF >=3D 32 VFs -> 2 queues per VF But, according to the datasheet it should be 16 VFs -> 8 queues per VF 32 VFs -> 4 queues per VF 64 VFs -> 2 queues per VF Am I missing something? One extra thing that I am not understanding, in the case I assign the maximum number of possible VFs, the PF remains without queues? There are a few other configurations such as if DCB is enabled I > believe it is possible to get 8 queues per VF if less than 16 VFs are > allocated but in such a case you would not have access to RSS. In > this case if the maximum combined queue count reported is 1 you would > need to check to see how many TCs are being supported by the PF in > order to determine if the queue count is 4 or 8 per VF. > > - Alex > Thank you very much, Mauricio V,