On Mon, Feb 15, 2016 at 02:16:16PM +0100, David Marchand wrote: Hello, > > On Sun, Feb 14, 2016 at 4:25 AM, Wu, Jingjing <jingjing.wu at intel.com> > wrote: > >> -----Original Message----- > >> From: David Marchand [mailto:david.marchand at 6wind.com] > >> Having this infrastructure is one thing, but the initial problem was that > >> the > >> driver did not recover from this reset event. > >> The linux i40e vf driver handles this kind of event itself. > >> Could we have something similar ? > >> > > > > Considering about the how to use DPDK PMD, and how to setup resource, we can > > know that lots of resources are managed by application. I think based on > > current > > PMD driver framework, driver cannot reset without application's help. > > I reported an issue on ixgbe. > What you provide here is a workaround for i40e. > I am not even sure this can be applied to ixgbe. > > Does it mean that anytime we have a problem with drivers, workarounds > should be applied to ethdev / eal ... so that you don't have to handle > anything in the drivers ? I think this patch provides a necessary framework for i40e VF to handle the asynchronous event, maybe Jingjing can help to change the description of this patch to let it does not limit to the VF reset event. > This is not the first time I complain about this kind of design issues. > > > > If we need to support driver recovery automatically, we'd better to find a > > way to do that. > > Do you have any idea? > > First, list those "lots of resources" that "are managed by application". > If your driver needs to keep track of those, this is i40e driver job > to do this internally without requiring ethdev to be modified. > > If this proves to be generic enough, maybe moving part of this to > ethdev will then make sense. > > > Thanks. > > -- > David Marchand Thanks,
Zhe Tao
