On Mon, Jul 09, 2007 at 07:21:24AM -0700, Veeraiyan, Ayyappan wrote: > >From: Neil Horman [mailto:[EMAIL PROTECTED] > >Replying to myself... > > I've looked through the driver pretty throughly with regards to > my > >above > >concern, and it appears the driver is reasonably free of netpoll issues > at > >the > >moment, at least as far as what we found in e1000 was concerned. I do > > Thanks for reviewing the code.. > > >however, > >see a concern in the use of the in_netpoll flag within the driver. > Given > >that > >the primary registered net_device, and all the dummy net_devices in the > >rx_ring > >point to the same ixgbe_adapter structure, there can be some level of > >confusion > >over weather a given rx queue is in netpoll_mode or not. > > The revised driver I am going to post today will not have fake > netdevs... > > >adapter prforms a netpoll, all the individual rx queues will follow the > >in_netpoll path in the receive path (assuming misx interrupts are > used). > >The > >result I think is the potential for a large amount of packet reordering > >during a > >netpoll operation. Perhaps not a serious problem, but likely worth > looking > > Multiple Rx queues are used in non-NAPI mode only, and all Rx queues use > one netdev (which is associated with the adapter struct). Also, the RSS > (receive side scaling or rx packet steering) feature is used in multiple > rx queues mode. In this mode, HW will always select the same Rx queue > (for a flow) and this should prevent any packet reordering issue. > > > >Neil > > Ayyappan
Thank you, I think that satisfies all my concerns. Regards Neil - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
