[dpdk-users] [dpdk-dev] DPDK Community Survey 2017

Kevin Traynor ktraynor at redhat.com
Thu Sep 28 15:58:02 CEST 2017

On 09/22/2017 11:47 AM, Jain, Deepak K wrote:
> Hi All,
> As part of our ongoing efforts to improve DPDK, we'd like to hear your feedback!
> We have created a number of DPDK-related questions here.
> https://www.surveymonkey.com/r/DPDK_Community_Survey_2017
> and want to hear your views!!
> The survey will close at midnight GMT on Sunday October 1st, 2017.
> Thanks in advance for your feedback - the more responses we get the more data we have to drive further features, improvements, etc.
> So please respond!!!
> Regards
> Deepak

Hi Deepak,

Thanks for the survey, I hope people will take the time to fill it out -
it was a recurring theme of the conference over the last few days that
more user input is needed. I'm not suggesting a survey on the survey ;-)
but a few comments below. Just my $0.02.

The deadline is really short - I'm not sure why the rush.

Some questions are for users and some for devs. Probably should note
that in the intro, so devs hang in there until the relevant questions.

Q5, I don't think it's a good idea to use radio buttons here, as a user
may have multiple applications. It would also be good to ask the stage
of applications. i.e. poc, development, product

Q10/Q12. I'm not sure if users of OVS will know under the hood if
OVS uses vhost pmd and vhost lib (it only uses vhost lib). You could
probably extrapolate from a combination of other answers, but anyway
both answers indicate vhost lib is being used and maybe that's good
enough info.

Q13. There should be an additional question on hardware generation. We
see hardware deprecation sometimes for older hardware, so need to ask
users which hardware generations they are using.

Q14. Probably this Q should allow multiple selections also.

Q15. It would be interesting to combine the kernels from the choices in
this question with the usage of KNI, igb_uio etc.

Q16. Does "usability of API", include release to release stability, or
just how easy it is to program against? I think maybe another option is

Q17. Typical trade offs between good and optimal performance should be
listed. Otherwise, why would anyone not say optimal. For example, things
like older hardware support, API/ABI stability etc. I'm sure there's others.


More information about the users mailing list