[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070705123705.GA19656@hmsreliant.homelinux.net>
Date: Thu, 5 Jul 2007 08:37:05 -0400
From: Neil Horman <nhorman@...driver.com>
To: "Veeraiyan, Ayyappan" <ayyappan.veeraiyan@...el.com>
Cc: Jeff Garzik <jeff@...zik.org>, netdev@...r.kernel.org,
"Kok, Auke-jan H" <auke-jan.h.kok@...el.com>,
arjan@...ux.intel.com, akpm@...ux-foundation.org
Subject: Re: [PATCH] ixgbe: Introduce new 10GbE driver for Intel 82598 based PCI Express adapters...
On Tue, Jul 03, 2007 at 08:53:46AM -0400, Neil Horman wrote:
> On Mon, Jul 02, 2007 at 12:00:29PM -0700, Veeraiyan, Ayyappan wrote:
> > On 7/2/07, Jeff Garzik <jeff@...zik.org> 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
>
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 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. When the primary
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 into
further.
Regards
Neil
--
/***************************************************
*Neil Horman
*Software Engineer
*Red Hat, Inc.
*nhorman@...driver.com
*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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists