On Mon, Jul 02, 2007 at 12:00:29PM -0700, Veeraiyan, Ayyappan wrote: > On 7/2/07, Jeff Garzik <[EMAIL PROTECTED]> wrote: > > Ayyappan Veeraiyan wrote: > > > +#define IXGBE_TX_FLAGS_VLAN_MASK 0xffff0000 > > > +#define IXGBE_TX_FLAGS_VLAN_SHIFT 16 > > > > defining bits using the form "(1 << n)" is preferred. Makes it easier > > to read, by eliminating the requirement of the human brain to decode > hex > > into bit numbers. > > > > > > Ok. > > > > + struct net_device netdev; > > > + }; > > > > Embedded a struct net_device into your ring? How can I put this? > > > > Wrong, wrong. Wrong, wrong, wrong. Wrong. > > > > Agreed. > Fake netdevs are needed for doing the multiple Rx queues in NAPI mode. > We are thinking to solve in 2 ways. Having netdev pointer in ring > structure or having an array of netdev pointers in ixgbe_adatper struct > which would be visible to all rings. > If thats what you're using the netdev pointers in the ring structure for, I'd like to remind you that you tried using Fake netdevs in e1000 last year, and the results were crashes and potential data corruption.
http://marc.info/?l=linux-netdev&m=114954878711789&w=2 The consensus there at the end of the above thread was to revert out the e1000 multiple rx queue code until such time as the netpoll code could be updated to better interoperate with multiple rx queues (Andy Grover I believe was the person who volunteered for the job). Given that I've not seen any netpoll updates regarding netpoll and multi-rx since then, I'm guessing the use of fake netdevs is still a problem. I've not checked this driver for all of the potential problems we found, but I will, and let you know if I see any. Regards Neil -- /*************************************************** *Neil Horman *Software Engineer *Red Hat, Inc. [EMAIL PROTECTED] *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ - 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
