From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by dpdk.org (Postfix) with ESMTP id 40ED0DE6 for ; Thu, 17 Dec 2015 11:30:55 +0100 (CET) Received: from pps.filterd (m0048192.ppops.net [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id tBH9sW9P012721; Thu, 17 Dec 2015 02:30:54 -0800 Received: from brmwp-exmb12.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 1yusdrr90e-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 17 Dec 2015 02:30:54 -0800 Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 17 Dec 2015 03:30:52 -0700 Received: from [10.252.48.20] (10.252.48.20) by EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 17 Dec 2015 11:30:48 +0100 To: "Ananyev, Konstantin" , Stephen Hemminger References: <1449853163-25673-1-git-send-email-stephen@networkplumber.org> <2601191342CEEE43887BDE71AB97725836AD3A0B@irsmsx105.ger.corp.intel.com> <20151214112516.35bbc1f8@xeon-e3> <2601191342CEEE43887BDE71AB97725836AD3A5C@irsmsx105.ger.corp.intel.com> <20151214133512.48593b49@xeon-e3> <2601191342CEEE43887BDE71AB97725836AD3DA2@irsmsx105.ger.corp.intel.com> From: Tom Kiely Message-ID: <56728ED2.8010509@brocade.com> Date: Thu, 17 Dec 2015 10:30:42 +0000 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <2601191342CEEE43887BDE71AB97725836AD3DA2@irsmsx105.ger.corp.intel.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.252.48.20] X-ClientProxiedBy: hq1wp-excas13.corp.brocade.com (10.70.36.103) To EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.21, 1.0.33, 0.0.0000 definitions=2015-12-17_01:2015-12-17,2015-12-17,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1511060000 definitions=main-1512170165 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH] ixgbe: Discard SRIOV transparent vlan packet headers. 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: Thu, 17 Dec 2015 10:30:55 -0000 Sorry for the delay in replying to this thread. I was on vacation for the last 3 days. Please see inline for my comments. On 12/15/2015 02:37 PM, Ananyev, Konstantin wrote: > >> -----Original Message----- >> From: Stephen Hemminger [mailto:stephen@networkplumber.org] >> Sent: Monday, December 14, 2015 9:35 PM >> To: Ananyev, Konstantin >> Cc: Zhang, Helin; dev@dpdk.org; Tom Kiely >> Subject: Re: [PATCH] ixgbe: Discard SRIOV transparent vlan packet headers. >> >> On Mon, 14 Dec 2015 19:57:10 +0000 >> "Ananyev, Konstantin" wrote: >> >>> >>>> -----Original Message----- >>>> From: Stephen Hemminger [mailto:stephen@networkplumber.org] >>>> Sent: Monday, December 14, 2015 7:25 PM >>>> To: Ananyev, Konstantin >>>> Cc: Zhang, Helin; dev@dpdk.org; Tom Kiely >>>> Subject: Re: [PATCH] ixgbe: Discard SRIOV transparent vlan packet headers. >>>> >>>> On Mon, 14 Dec 2015 19:12:26 +0000 >>>> "Ananyev, Konstantin" wrote: >>>> >>>>> >>>>>> From: Stephen Hemminger [mailto:stephen@networkplumber.org] >>>>>> Sent: Friday, December 11, 2015 4:59 PM >>>>>> To: Zhang, Helin; Ananyev, Konstantin >>>>>> Cc: dev@dpdk.org; Tom Kiely; Stephen Hemminger >>>>>> Subject: [PATCH] ixgbe: Discard SRIOV transparent vlan packet headers. >>>>>> >>>>>> From: Tom Kiely >>>>>> >>>>>> SRIOV VFs support "transparent" vlans. Traffic from/to a VM >>>>>> associated with a VF is tagged/untagged with the specified >>>>>> vlan in a manner intended to be totally transparent to the VM. >>>>>> >>>>>> The vlan is specified by "ip link set vf vlan ". >>>>>> The VM is not configured for any vlan on the VF and the VM >>>>>> should never see these transparent vlan headers for that reason. >>>>>> >>>>>> However, in practice these vlan headers are being received by >>>>>> the VM which discards the packets as that vlan is unknown to it. >>>>>> The Linux kernel explicitly discards such vlan headers but DPDK >>>>>> does not. >>>>>> This patch mirrors the kernel behaviour for SRIOV VFs only >>>>> >>>>> I have few concerns about that approach: >>>>> >>>>> 1. I don't think vlan_tci info should *always* be stripped by vf RX routine. >>>>> There could be configurations when that information might be needed by upper layer. >>>>> Let say VF can be member of 2 or more VLANs and upper layer would like to have that information >>>>> for further processing. >>>>> Or special mirror VF, that does traffic snnoping, or something else. >>>>> 2. Proposed implementation would introduce a slowdown for all VF RX routines. >>>>> 3. From the description it seems like the aim is to clear VLAN information for the RX packet. >>>>> Though the patch actually clears VLAN info only for the RX packet whose VLAN tag is not present inside SW copy of VFTA table. >>>>> Which makes no much point to me: >>>>> If VLAN is not present in HW VFTA table, then packet with that VLAN tag will be discarded by HW anyway. >>>>> If it is present inside VFTA table (both SW & HW), then VLAN information would be preserved with and without the patch. >>>>> >>>>> If you need to clear VLAN information, why not to do it on the upper layer - inside your application itself? >>>>> Either create some sort of wrapper around rx_burst(), or setup an RX call-back for your VF device. >>>>> >>>>> Konstantin >>>> >>>> The aim is to get SRIOV to work when the transparent VLAN tag feature is used. >>>> Please talk to the Linux driver team. Similar code exists there in ixgbevf_process_skb_fields. >>> >>> Ah ok, I realised what you are trying to achieve now: >>> You setup HW VFTA[] from the PF, so from VF point of view SW copy of the VFTA[] remains unset. >>> So HW will pass VLAN packet in, but then SW will clear VLAN tag. >>> Ok, that clears #3 above, but I think #1,2 still remain. >> On the host, what configured is a vlan tag per VF per guest >> >> Tom had more info in the original mail. >> >> http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/28932 >> >>>> The other option is have a copy of all the receive logic which is only >>>> used by VF code. >>> Why that's the only option? >>> Why can't you clear that VLAN information above the PMD layer? >>> Keep/obtain a copy of VFTA[] somewhere on the upper layer, >>> and do actual clear after rx_burst() returns? >>> Konstantin >> The problem is that the guest is supposed to not see the VLAN tags (it has no reason to), >> but the hardware leaves a VLAN tag on there. > Yes, I understand what you are trying to achieve. > What I am trying to say: > 1. VLAN tag removing shouldn't be forced for all VFs. > I think there are scenarios where existing behaviour (keeping vlan_tci and ol_flags intact) are what people need. > One example would be mirror VF doing other VFs traffic snooping. > Probably some other cases too. > 2. The way you implemented it - it might cause a RX performance degradation (specially for VF). > That's why I think it better to be implemented on top of PMD: > i.e: some sort of wrapper that checks all packets returned by rx_burst() and clears vlan_tci if needed. > That would give you desired behaviour and keep current implementation intact. > > Konstantin > > > > Hi Konstantin, To address your comments: (1) Only tags corresponding to VLANs that the client knows nothing about are stripped. These tags are not intended to be seen by the client. Maybe your concern would be addressed by disabling this functionality when snooping in the same way that vlan offloading is disabled ? I think further analysis is required here on our part. (2) In relation to performance, for the non-SRIOV case, the hit is one "if" per packet to test whether the functionality is enabled or not. We saw no significant performance impact for the SRIOV case. Moving the functionality above PMD is certainly something that we can examine. Thanks, Tom >