Re: [net-next PATCH 1/2] igbvf: add new driver to support 82576 virtual functions

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Andrew Morton
Date: Tuesday, March 10, 2009 - 10:21 pm

On Tue, 10 Mar 2009 19:09:28 -0700 Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:


The drive-by reader is now wondering what a "virtual function" is.
 

<stares at it for a while>

It would be clearer if `m' and `b' were (much) more meaningful identifiers.


This is ARRAY_SIZE().


Why does this need to exist?


No timeout needed here?  Interrupts might not be working, for example..


That's odd-looking.  Why take a copy of rx_old and tx_old when we're
about to free them?


If this process has signal_pending(), msleep_interruptible() becomes a
no-op.  I expect the driver breaks?


yitch.

Are we using the C type system as well as possible here?


my eyes.

This macro evaluates its argument multiple times and will misbehave (or
be slow) if passed an expreesion with side-effects.

Why not just write a plain old C function for this?


Maybe igbvf_ring.desc should have had type

	union {
		union e1000_adv_rx_desc;
		union e1000_adv_tx_desc;
		union e1000_adv_tx_context_desc;
	} *

Or something.


Does wmb() work reliably for masters other than CPUs?  I lose track...


How large is this likely to be?


This can run pci_disable_msix() even if pci_enable_msix() falied.  Seems odd.


The error handling here is all mucked up.


It is conventional to terminate a kerneldoc comemnt with

    */


Shouldn't this be reported to someone?


Random mysterious msleep() deserves a code commeent.


timeout?


Could use setup_timer() here.


flush_work() is a bit more modern - it will flush a specific work item
rather than waiting for the kernel-wide queue to drain.


What a lot of code.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [net-next PATCH 1/2] igbvf: add new driver to support ..., Andrew Morton, (Tue Mar 10, 10:21 pm)