Re: [Xen-devel] confusion on front end driver and allox_rx_buffers.

[Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>]

On Tue, Sep 14, 2004 at 10:09:58PM -0600, Ronald G. Minnich wrote:
> np->rx_resp_cons is I think the number that says which buffer we are 
> consuming, and increases from 0 -> infinity. 

Yes.  But note that it is not part of the interface to Xen.

> np->rx->req_prod is Xen's count of which buffer it has produced, and it 
> also increase from 0 -> infinity.

No.  rx->req_prod is the index of the last buffer we have provided
to Xen.  rx->resp_prod is what you described, i.e. the index of the
buffer Xen has filled last.

There are two sets of indexes, one to pass buffers to Xen and one
for Xen to pass buffers back.

> Your goal is to consume buffers from the rx ring as Xen fills them. You 
> want to try to catch np->rx_resp_cons to np->rx->req_prod (I assume). You 
                                        to np->rx->resp_prod
> get interrupts as buffers become available, i.e. are filled in by Xen. 
> 
> Pretend we get a packet and netif_poll gets called. I expect (?) that
> np->rx->req_prod is 1. netif_poll will eat the buffer, and now the ring

np->rx->req_prod should be equal to NETIF_RX_RING_SIZE or however many
buffers you have provided to Xen initially.  If you provide less than
NETIF_RX_RING_SIZE, you have to have another exit out of the loop...

    christian



-------------------------------------------------------
This SF.Net email is sponsored by: thawte's Crypto Challenge Vl
Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam
Camcorder. More prizes in the weekly Lunch Hour Challenge.
Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel