From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <arybchenko@solarflare.com> Received: from nbfkord-smmo02.seg.att.com (nbfkord-smmo02.seg.att.com [209.65.160.78]) by dpdk.org (Postfix) with ESMTP id 50495B33E for <dev@dpdk.org>; Fri, 2 Dec 2016 10:00:05 +0100 (CET) Received: from unknown [193.34.186.16] (EHLO webmail.solarflare.com) by nbfkord-smmo02.seg.att.com(mxl_mta-7.2.4-7) with ESMTP id 51831485.2b0835087940.108028.00-2492.249155.nbfkord-smmo02.seg.att.com (envelope-from <arybchenko@solarflare.com>); Fri, 02 Dec 2016 09:00:05 +0000 (UTC) X-MXL-Hash: 584138157ab9273c-0aea0a261f033bd4e8460d3ab5662aa24e3b91f7 Received: from unknown [193.34.186.16] (EHLO webmail.solarflare.com) by nbfkord-smmo02.seg.att.com(mxl_mta-7.2.4-7) over TLS secured channel with ESMTP id 21831485.0.108026.00-2350.249151.nbfkord-smmo02.seg.att.com (envelope-from <arybchenko@solarflare.com>); Fri, 02 Dec 2016 09:00:04 +0000 (UTC) X-MXL-Hash: 5841381470ae06e4-cba0d6da4eded8cde4a1fa8e3de0cb6ff1e094c4 Received: from [192.168.38.17] (84.52.89.52) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 2 Dec 2016 08:59:37 +0000 To: Wenzhuo Lu <wenzhuo.lu@intel.com>, <dev@dpdk.org> References: <1480637533-37425-1-git-send-email-wenzhuo.lu@intel.com> From: Andrew Rybchenko <arybchenko@solarflare.com> Message-ID: <27bd35a3-397c-6a4b-bc78-78eb3370d178@solarflare.com> Date: Fri, 2 Dec 2016 11:59:32 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <1480637533-37425-1-git-send-email-wenzhuo.lu@intel.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [84.52.89.52] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-11.0.0.1191-8.000.1202-22736.003 X-TM-AS-Result: No--8.192900-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-AnalysisOut: [v=2.1 cv=NIXTjhOg c=1 sm=1 tr=0 a=8P+NB+fYZDP74ap4g4d9Kw==] X-AnalysisOut: [:17 a=RB3BGLmKESwA:10 a=IkcTkHD0fZMA:10 a=n5n_aSjo0skA:10 ] X-AnalysisOut: [a=lKenU9Wm8SsiejgZZ6wA:9 a=QEXdDO2ut3YA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2015072901)] X-MAIL-FROM: <arybchenko@solarflare.com> X-SOURCE-IP: [193.34.186.16] Subject: Re: [dpdk-dev] [PATCH 00/31] Support VFD and DPDK PF + kernel VF on i40e X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Fri, 02 Dec 2016 09:00:05 -0000 On 12/02/2016 03:11 AM, Wenzhuo Lu wrote: > 1, VF Daemon (VFD) > VFD is an idea to control all the VFs from PF. > As we need to support the scenario kernel PF + DPDK VF, DPDK follows the interface > between kernel PF + kernel VF. We don't want to introduce too many new messages > between PF and VF. So this patch set adds some new APIs to control VFs directly > from PF. > The new APIs include, > 1) set VF MAC anti-spoofing > 2) set VF VLAN anti-spoofing > 3) set TX loopback > 4) set VF unicast promiscuous mode > 5) set VF multicast promiscuous mode > 6) set VF MTU > 7) get/reset VF stats > 8) set VF MAC address > 9) set VF VLAN stripping > 10) VF VLAN insertion > 12) set VF broadcast mode > 12) set VF VLAN tag > 13) set VF VLAN filter > VFD also includes VF to PF mailbox message management by APP. When PF receives mailbox > messages from VF, PF should call the callback provided by APP to know if they're > permitted to be processed. The patch series adds i40e-specific API functions for VF control (advertise link status change, MAC anti-spoofing, VLAN anti-spoofing, promiscuous mode, MAC change, VLAN controls), but RTE API is added to get VF stats. I'm wondering why. Corresponding patches do not explain why i40e-specific API is added instead of generic RTE API. IMHO, it is hardly convenient for applications. (I guess it was a discussion and decision, but I've failed to find in the archive). Andrew.