Many thanks.
and netbk_tx_pending_timeout() is added since xen3.2. I've not found this
timer in xen3.1.
===================================
what about another question:
In netback netif_be_start_xmit()
if (!netif->copying_receiver ||
((skb_headlen(skb) + offset_in_page(skb->data)) >= PAGE_SIZE)) {
struct sk_buff *nskb = netbk_copy_skb(skb);
which calls skb_copy_bits()
it means when rx-flip, the skb data and frags are copied to another buffer.
then the buffer flip with domU's pages.
so before page flip with domU, copying happens in dom0. Does rx-flip make any
sense?
======= 2008-06-23 19:22:37 您在来信中写道：=======
>> 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
>
= = = = = = = = = = = = = = = = = = = =
Zang Hongyong
zanghongyong@xxxxxxxxxx
2008-06-23
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home