Re: [dpdk-dev] [PATCH v4 0/4] net/softnic: sw fall-back pmd for traffic mgmt and others

[Thomas Monjalon <thomas@monjalon.net>]

06/10/2017 12:40, Dumitrescu, Cristian:
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > 18/09/2017 11:10, Jasvinder Singh:
> > > The SoftNIC PMD is intended to provide SW fall-back options for specific
> > > ethdev APIs in a generic way to the NICs not supporting those features.
> > 
> > I agree it is important to have a solution in DPDK to better manage
> > SW fallbacks. One question is to know whether we can implement and
> > maintain many solutions. We probably must choose only one solution.
> > 
> > I have not read the code. I am just interested in the design for now.
> > I think it is a smart idea but maybe less convenient than calling fallback
> > from ethdev API glue code. My opinion has not changed since v1.
> > Thanks for the detailed explanations. Let's discuss below.
> > 
> 
> Don't understand me wrong, I would also like to have the single device solution (hard NIC augmented with SW-implemented features) as opposed to the current proposal, which requires two devices (hard device and soft device acting as app front-end for the hard device).
> 
> The problem is that right now the single device solution is not an option with the current librte_ether, as there simply a lot of changes required that need more time to think through and get agreement, and likely several incremental stages are required to make it happen. As detailed in the Dublin presentation, they mostly refer to:
> - the need of the SW fall-back to maintain its owns data structures and functions (per device, per RX queue, per TX queue)
> - coexistence of all the features together
> - how to bind an ethdev to one (or several) SW threads
> - thread safety requirements between ethdev SW thread and app threads
> 
> Per our Dublin discussion, here is my proposal:
> 1. Get Soft NIC PMD into release 17.11.
> 	a) It is the imperfect 2-device solution, but it works and provides an interim solution.
> 	b) It allows us to make progress on the development for a few key features such as traffic management (on TX) and hopefully flow & metering (on RX) and get feedback on this code that we can later restructure into the final single-device solution.
> 	c) It is purely yet another PMD which we can melt away into the final solution later.
> 2. Start an RFC on librte_ether required changes to get the single-device solution in place.
> 	a) I can spend some time to summarize the objectives, requirements, current issues and potential approaches and send the first draft of this RFC in the next week or two?
> 	b) We can then discuss, poll for more ideas and hopefully draft an incremental path forward
> 
> What do you think?

I think temporary solutions (which often become definitive) must be avoided,
especially when it implies new API.
In the case of softnic, there is no new API really, just a new workflow
for applications and some new driver parameters.
So my conclusion is that we should merge and experience it.
It does not prevent from working on another solution, as you suggest.

Acked-by: Thomas Monjalon <thomas@monjalon.net>

PS: thank you for having given your opinion on other questions