From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Samudrala, Sridhar" Subject: Re: SRIOV switchdev mode BoF minutes Date: Thu, 12 Apr 2018 13:33:41 -0700 Message-ID: References: <64cca3cd-5592-8210-54c4-ed28c284ae5d@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: David Miller , Anjali Singhai Jain , Andy Gospodarek , Michael Chan , Simon Horman , Jakub Kicinski , John Fastabend , Saeed Mahameed , Jiri Pirko , Rony Efraim , Linux Netdev List To: Or Gerlitz Return-path: Received: from mga04.intel.com ([192.55.52.120]:45952 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751009AbeDLUdm (ORCPT ); Thu, 12 Apr 2018 16:33:42 -0400 In-Reply-To: Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 4/12/2018 1:20 PM, Or Gerlitz wrote: > On Thu, Apr 12, 2018 at 8:05 PM, Samudrala, Sridhar > wrote: >> On 11/12/2017 11:49 AM, Or Gerlitz wrote: >>> Hi Dave and all, >>> >>> During and after the BoF on SRIOV switchdev mode, we came into a >>> consensus among the developers from four different HW vendors (CC >>> audience) that a correct thing to do would be to disallow any new >>> extensions to the legacy mode. >>> >>> The idea is to put focus on the new mode and not add new UAPIs and >>> kernel code which was turned to be a wrong design which does not allow >>> for properly offloading a kernel switching SW model to e-switch HW. >>> >>> We also had a good session the day after regarding alignment for the >>> representation model of the uplink (physical port) and PF/s. >>> >>> The VF representor netdevs exist for all drivers that support the new >>> mode but the representation for the uplink and PF wasn't the same for >>> all. The decision was to represent the uplink and PFs vports in the >>> same manner done for VFs, using rep netdevs. This alignment would >>> provide a more strict and clear view of the kernel model for e-switch >>> to users and upper layer control plane SW. >>> >> I don't see any changes in the Mellanox/other drivers to move to this new >> model to enable the uplink and PF port representors, any updates? > Yeah, I am worked on that but didn't get to finalize the upstreaming > so far. I have resumed > the work and plan uplink rep in mlx5 to replace the PF being uplink rep for 4.18 > >> It would be really nice to highlight the pros and cons of the old versus the >> new model. >> >> We are looking into adding switchdev support for our new 100Gb ice driver >> and could use some feedback on the direction we should be taking. > good news. > > The uplink rep is clear cut that needs to be a rep device representing > the uplink just like vf > rep represents the vport toward the vf - please just do it correct > from the begining > Having an uplink rep will definitely help implement the slow path with flat/vlan network scenarios by not having to add PF to the bridge. But how do they help with a vxlan overlay scenario? In case of overlays, the slow path has to go via vxlan -> ip stack -> pf? What about pf-rep?