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