From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) by dpdk.org (Postfix) with ESMTP id 748EB590C for ; Tue, 6 Jan 2015 12:18:34 +0100 (CET) Received: by mail-we0-f181.google.com with SMTP id q58so9544123wes.12 for ; Tue, 06 Jan 2015 03:18:34 -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 :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=kaa5h750dKkSpaEH5xCjbXhJ/6D5gHmal7uivrv4PEI=; b=Kq2IQEYr/jap3u8XNKmfStJPkXWtxdTfNEGZ7sw+HFT+MZs41YkN3aYNB1kE82rY+v YngGIYG9SmcvySxSXRwuWFfXLCpI6pVYz6JFfrZiqsaNW8iLgN5TEGIFufjOvfcN3RaC NcaTnpwiAnGcGb4DE1iKsw86A3Aoi/XNtd9TzaB5pyxmg4XSl86m+2TJc01jW5WW8JGn JBcBTkHVLsRXZhu/4fnS+iBX5jrNRZbXvyut6VTNd+Uqy7puwJbGaLImxp2F/MOve7z+ DS5QGAygBh+L/iDtQXo+gaeMimD957G4pBvShiVqo4RyPW6ofW5hRj8F1ZrHxnHazKJY Hq1Q== X-Gm-Message-State: ALoCoQlb8ld5RLKKO9anlT7InbReD+y2nSyOktwxEX3+9D1XWWduDagPmq0j4K/ZMNg8OVtn/9Uo X-Received: by 10.194.174.3 with SMTP id bo3mr188143761wjc.98.1420543114290; Tue, 06 Jan 2015 03:18:34 -0800 (PST) Received: from [10.0.0.165] (system.cloudius-systems.com. [84.94.198.183]) by mx.google.com with ESMTPSA id ud4sm13565750wib.0.2015.01.06.03.18.31 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jan 2015 03:18:33 -0800 (PST) Message-ID: <54ABC485.2060806@cloudius-systems.com> Date: Tue, 06 Jan 2015 13:18:29 +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" , "Richardson, Bruce" References: <1419389808-9559-1-git-send-email-changchun.ouyang@intel.com> <1419398584-19520-1-git-send-email-changchun.ouyang@intel.com> <549A8E7C.7010806@cloudius-systems.com> <20150105103802.GB13152@bricha3-MOBL3> <54AA8B64.4060602@cloudius-systems.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v3 0/6] Enable VF RSS for Niantic 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: Tue, 06 Jan 2015 11:18:34 -0000 On 01/06/15 03:11, Ouyang, Changchun wrote: > >> -----Original Message----- >> From: Vlad Zolotarov [mailto:vladz@cloudius-systems.com] >> Sent: Monday, January 5, 2015 9:02 PM >> To: Richardson, Bruce; Ouyang, Changchun >> Cc: dev@dpdk.org >> Subject: Re: [dpdk-dev] [PATCH v3 0/6] Enable VF RSS for Niantic >> >> >> On 01/05/15 12:38, Bruce Richardson wrote: >>> On Thu, Dec 25, 2014 at 01:46:54AM +0000, Ouyang, Changchun wrote: >>>> Hi, >>>> >>>>> -----Original Message----- >>>>> From: Vlad Zolotarov [mailto:vladz@cloudius-systems.com] >>>>> Sent: Wednesday, December 24, 2014 5:59 PM >>>>> To: Ouyang, Changchun; dev@dpdk.org >>>>> Subject: Re: [dpdk-dev] [PATCH v3 0/6] Enable VF RSS for Niantic >>>>> >>> > >>>>> On the contrary - it's a very good idea! We use DPDK on Amazon's >>>>> guests with enhanced networking and we have no access to the PF. We >>>>> still need to know the RSS redirection rules for our VF pool. From >>>>> the 82599 spec, chapter >>>>> 4.6.10.1.1: "redirection table is common to all the pools and only >>>>> indicates the queue inside the pool to use once the pool is chosen". >>>>> In that case we need to get the whole 128 entries of the RETA. Is >>>>> there a reason why we can't have it? >>>>> >>>> Due to hardware limitation, VF could not query its own reta table, >>>> because there is not its own reta, The reta table shared by pf and all vfs. >>>> If you need know it, query them on pf is feasible way to do it. >>>> >>> It's not feasible if you only have access to a guest. :-) IMHO since >>> the guest is seeing the results of the RSS redirection table, it >>> should be able to query the table, if it wants. It should not, >>> however, be able to modify the table, as it is owned by the PF. >> This is exactly what I meant! ;) >> The problem at the moment is that upstream PF driver has no VF-PF >> command for that and I'm in the process of pushing the patch for it. >> Then it's accepted (and pushed into the Amazon's HV ;)) then DPDK's VF >> driver may proceed with what u and me are suggesting. > Besides lack of command between pf and vf, another issue, pf also need know which entries from the whole 128 entries in reta table are assigned > To a specified vf. First of all PF knows since it configures it for a VF in a x550 and for older devices the (whole) RETA is shared between the PF and VF. There is a per-pool RTYPE[n].RQPL register that defines the number of lsb's from the redirection table to consider (see my patch series "ixgbevf: Allow querying VFs RSS indirection table and key" in the netdev list). > >> Not related question to Intel guys: I can't find a x550 spec in the net. >> Can anybody tell me where it may be found? ;) > AFAIK, not yet Well, too bad... ;) I'll have to hope I guessed right during the driver reverse engineering... ;) > >>> Regards, >>> /Bruce >>>