On Tue, Nov 14, 2017 at 3:36 PM, Jakub Kicinski <jakub.kicin...@netronome.com> wrote: > On Tue, 14 Nov 2017 15:05:08 -0800, Alexander Duyck wrote: >> >> We basically need to do some feasability research to see if we can >> >> actually meet all the requirements for switchdev on i40e. We have been >> >> getting mixed messages where we are given a great many "yes, but" type >> >> answers. For i40e we are looking into it but I don't have high >> >> confidence in our ability to actually support it in hardare/firmware. >> >> If it were as easy as you have been led to believe, we would have done >> >> it months ago when we were researching the requirements to support >> >> switchdev >> > >> > wait, Sridhar made seven rounds of his submission (this is the v7 >> > pointer [1]) and you >> > still don't know if what you were attempting to push upstream can >> > work, something is >> > weird here, can you clarify? Jeff? >> >> Not weird so much as stubborn. The patches were being pushed based on >> the assumption that the community would accept a NIC generating port >> representors that didn't necessarily pass traffic, and then even when >> we had them passing traffic the PF still wasn't configured to handle >> being the default destination for traffic without any rules >> associated, instead VFs would directly send to the outside world. > > Perhaps the way forward is to lift the requirement on passing traffic, > as long as the limitation is clearly expressed to the users.
No, I am not arguing for that because then SwitchDev will fall into disarray. If we want to have a strict definition for what is SwitchDev and what isn't I am okay with that. It gives us a definition of what our hardware needs to do in order to support it and without that we are going to get hardware that just bends the rules to claim support for it. All I am asking for is for us to not close the door to the possibility of adding features to legacy SR-IOV. I am hoping to use a source macvlan based approach to make it so that we can support "port representors" for devices that can't support full SwitchDev. The idea would be to use them to get as close to SwitchDev level support on legacy devices as possible without using full SwitchDev. That should solve a good part of the issue, but I am pretty certain I need to be able to extend legacy SR-IOV in order to support it. I had talked with Jiri at netdev 2.1 about it back when we had submitted the v7 patches, and the decision was to look at doing "port representors" but don't associate them with SwitchDev. I was out on Sabbatical for most of the summer and I am just now starting on the macvlan work I had planned. I hope to have it done before the next netdev and then we can discuss it there if it needs more discussion than what we can have on the mailing list. I'm fine with us placing any legacy SR-IOV changes under more scrutiny. I am just not open to saying we will not extend or update any features for legacy SR-IOV. The fact is we are still selling a ton of ixgbe based parts, so I can't say with any certainty that there won't be a request for some new SR-IOV feature in the future. - Alex
