WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] confusion on front end driver and allox_rx_buffers.
From: "Ronald G. Minnich" <rminnich@xxxxxxxx>
Date: Tue, 14 Sep 2004 22:09:58 -0600 (MDT)
Delivery-date: Wed, 15 Sep 2004 05:16:58 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
In the frontend ethernet driver, there is a ring buffer of buffers 
pointers -- skbs are used on linux. 

np->rx_resp_cons is I think the number that says which buffer we are 
consuming, and increases from 0 -> infinity. 
np->rx->req_prod is Xen's count of which buffer it has produced, and it 
also increase from 0 -> infinity. Driver uses good old fashioned 
power-of-two ring sizes and masks to to turn these counts into indices in 
the ring. 

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 
get interrupts as buffers become available, i.e. are filled in by Xen. 

Initially, network startup calls network_alloc_rx_buffers to set up the 
ring with a set of skbs, and hands MFNs of these skbs to Xen in a shared 
array that implements the ring buffer. 

Initially all counters are zero (cons and prod).

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
has had a buffer consumed, so netif_poll will call
network_alloc_rx_buffers to refill the ring.

I see this:

    do {
        skb = dev_alloc_skb(RX_BUF_SIZE);
        .
        .
        .
        id = GET_ID_FROM_FREELIST(np->rx_skbs);

        np->rx_skbs[id] = skb;
        
        np->rx->ring[MASK_NETIF_RX_IDX(i)].req.id = id;
        .
        .
        nr_pfns++;
    }
    while ( (++i - np->rx_resp_cons) != NETIF_RX_RING_SIZE );

OK, the question: I only consumed one buffer, why is this code refilling 
the whole ring this way? What's happening to me is that the id = 
GET_ID_FROM_FREELIST is failing badly because the do loop is running from 
2 to NETIF_RX_RING_SIZE, which is wrong. 

I think I'm getting caught between the differences in Plan 9 and Linux net 
interrupt handling, which I don't fully understand yet, but some of this 
ether xen front end code has me confused. 

Comments and clarification are most welcome :-)

ron
p.s. and yes, I am at the DHCP step and it's damn near working. 


-------------------------------------------------------
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

<Prev in Thread] Current Thread [Next in Thread>