[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re: [Xen-devel] SetPageForeign in netback



thanks. Maybe I understand.
Another question
In netback:
static inline void maybe_schedule_tx_action(void)
{
        smp_mb();
        if ((NR_PENDING_REQS < (MAX_PENDING_REQS/2)) &&
            !list_empty(&net_schedule_list))
                tasklet_schedule(&net_tx_tasklet);
}
... ...

while 
#define NR_PENDING_REQS (MAX_PENDING_REQS - pending_prod + pending_cons)
that is NR_PENDING_REQS = MAX_PENDING_REQS - (pending_prod - pending_cons)

My question is when NR_PENDING_REQS cannot satisfy the above condition  
"(NR_PENDING_REQS < (MAX_PENDING_REQS/2)"?
why not handle the condition of "NR_PENDING_REQS >= (MAX_PENDING_REQS/2)"?
        

======= 2008-06-19 15:22:58 您在来信中写道:=======

>The aim is to achieve batching and scheduling of work (to some extent) on
>both the transmit and receive paths. So no vif gets starved, and larger
>batches of packets are handled more efficiently.
>
> -- Keir
>
>
>On 19/6/08 01:40, "Zang Hongyong" <zanghongyong@xxxxxxxxxx> wrote:
>
>> Thanks again!
>> Another question about netback.
>> tasklet is used in both tx and rx. Lets take a look at rx, Before tasklet,
>> packets of all vnifs must be queued together, and in tasklet packet will be
>> dequeued, and handled to its proper netfront of domU.
>> 1)why not handle packet directly without the overall queue and tasklet stuff?
>> 2)Is the overall queue and tasklet stuff fair to all vnifs? For example, when
>> vif1.0 rx, the netback driver put its packet to overall queue and do tasklet,
>> while in tasklet, packets belonging to other vif maybe handled.
>>   I've noticed when tx, netfront handle packet directly to its proper
>> Ring,Request stuff.
>> 
>> 
>> 
>> ======= 2008-06-19 00:37:40 您在来信中写道:=======
>> 
>>>> Many thanks!
>>>> And that is, when tx, after the data page is sent by native Nic driver in
>>>> dom0, the data page will be freed, then netif_page_release() called which
>>>> indicates netback to unmap the page offered by domU, and moves on its tx
>>>> response.
>>>> 
>>>> Is that so?
>>> 
>>> Correct.
>>> 
>>>> If so, how about a bad NIC driver which doen't call free_page() after
>>>> sending data out of machine ?
>>> 
>>> Well, it could happen if there was a memory leak in the driver. This
>>> would also be present in non-xenified linux. We are hoping for
>>> bug-free device drivers.
>>> 
>>> 
>>>> and Why mmap_pages is allocated by
>>>> alloc_empty_pages_and_pagevec(MAX_PENDING_REQS)?
>>>> can  mmap_pages be allocated by alloc_vm_area() and vmalloc_to_page() ??
>>> 
>>> alloc_empty_pages_and_pagevec() balloons machine memory frames away
>>> from Dom0, you are therefore left with pseudo-physical page that's not
>>> backed by real memory. You want that, because you'll substitute DomU's
>>> memory frame in it's place. I don't think alloc_vm_area does that. It
>>> would only allocate virtually continuous range of memory.
>>> 
>>> Cheers
>>> Gr(z)egor(z)
>>> 
>>>> 
>>>> Forgive my silly questions above please.
>>>> 
>>>> 
>>>> ======= 2008-06-18 18:52:27 您在来信中写道:=======
>>>> 
>>>>>> hi,
>>>>>>  in netback init mmap_pages,
>>>>>>                SetPageForeign(page, netif_page_release);
>>>>>>  that is, page->index = netif_page_release
>>>>>>  while netif_page_release is a function.
>>>>> 
>>>>> netif_page_release is a function, and therefore:
>>>>> page->index = netif_page_release
>>>>> will store netif_page_release function pointer in 'index'
>>>>> 
>>>>>>  so what's the meaning of SetPageForeign?
>>>>> 
>>>>> Setting a page foreign means that the page is owned by another domain,
>>>>> and that some care needs to be taken when freeing it.
>>>>> 
>>>>>>  And when the function  netif_page_release() will be called?
>>>>> 
>>>>> Whenever PageForeignDestructor is called (as it calls the destructor
>>>>> function stored in the 'index' field).
>>>>> PageForeignDestructor is called from:
>>>>> __free_pages_ok
>>>>> and
>>>>> free_hot_cold_page
>>>>> 
>>>>> Hope this helps.
>>>>> 
>>>>> Cheers
>>>>> Gr(z)egor(z)
>>>>> 
>>>>> _______________________________________________
>>>>> Xen-devel mailing list
>>>>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>>>>> http://lists.xensource.com/xen-devel
>>>>> 
>>>>> 
>>>> 
>>>> = = = = = = = = = = = = = = = = = = = =
>>>> Zang Hongyong
>>>> zanghongyong@xxxxxxxxxx
>>>> 2008-06-18
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>>>> http://lists.xensource.com/xen-devel
>>>> 
>>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>>> http://lists.xensource.com/xen-devel
>>> 
>> 
>> = = = = = = = = = = = = = = = = = = = =
>> Zang Hongyong
>> zanghongyong@xxxxxxxxxx
>> 2008-06-19
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
>
>
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-devel

= = = = = = = = = = = = = = = = = = = =
Zang Hongyong
zanghongyong@xxxxxxxxxx
2008-06-22

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.