> 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)"?
If there are many pending requests (more then MAX/2), new requests
will have to wait on frontend-backend rings (a form of congestion
control). When some of the pending requests get dealt with (and
NR_PENDING_REQS falls below MAX/2) new ones will be accepted.
Also, note that net_tx_tasklet doesn't only get scheduled by
maybe_schedule_tx_action. There also is:
- netbk_tx_pending_timeout: triggered by a timeout timer
- netif_idx_release: triggered by a net data page being released
The three net_tx_tasklet schedulers guarantee continuous flow of skbs
out of netback.
Cheers
Gr(z)egor(z)
>
>
> ======= 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
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home