[gPXE-devel] [PATCH] [jme] Adding JMicron Ethernet driver

[Guo-Fu Tseng]

On Sat, 29 May 2010 16:27:55 +0100, Michael Brown wrote
> On Saturday 29 May 2010 09:35:10 Guo-Fu Tseng wrote:
> > > > +	rxdesc += idx;
> > > > +	if (jme_make_new_rx_buf(rxring->bufinf + idx)) {
> > > > +		DBG("Dropped packet due to memory allocation error.\n");
> > > > +		netdev_rx_err(netdev, NULL, -ENOMEM);
> > > > +	} else {
> > >
> > > This will behave poorly when memory runs out.  Better is to have a
> > > refill routine that runs after the poll(), and always attempts to
> > > refill up to a specified level (failing silently if it cannot allocate
> > > a buffer).
> > 
> > I'm sorry I don't quite sure about the idea.
> > Do you mean I should treat this packet as it's avaliable(Which makes sence
> > in intuition), and try to allocate the receive buffer later in poll()?
> 
> Yes.  Take a look at something like drivers/net/b44.c, and the 
> b44_rx_refill() function.

After some thought, I believe you have a good point.

Although I did that intentionally, but I'm afriad I might did the
wrong thing in gPXE. So I took some time think about it before I
reply this mail.

Currently we are passing io_buffer from UDP/TCP to upper layer via
xfer_deliver_iob*, even if upper layer defined .deliver_iob as
xfer_deliver_as_raw(), won't need any extra memory allocation.
(Not considering the memory allocations within app layer protocols
itself, just the xfer action.)

So that if we are at edge of the avaliable memory, passing the iob
to upper which would be freed, before allocating new buffer for
hardware ring-buffer might work better in this case.

I traced several drivers before I wrote Linux driver, and for this
behavior I referenced the bnx2 driver (bnx2_rx_skb()). Instead of
feed it to the upper layer while out of memory, I reused the buffer
for hardware to continue working.

The reason I choose this behavior is that if we really at very low
memory status, and the app layer somehow requires more memory as we
feed data in. In the worst case, if we fail to allocate buffer for
hardware ring every time. We'll have an ring-descriptor which is totally
NOT OWNED by hardware.

I don't want that case to happen. Because once we are in that state,
the hardware RX engine will be stopped. And I can't think of a good
point to make it restart other than trying to allocate memory every
time the poll function is called.

It is not harmful if the poll function was called periodicly instead
of triggered by interrupt(which it is). Because as soon as we have
memory we can bring on the MAC processor. But with interrupt driven
setup, the hardware might stop indefinitely.

In summary, it gPXE will never call poll depend on interrupt.
I belived it would help on extreme low memory status to modify
it to the behavior Michael Brown suggested. :)

Guo-Fu Tseng