[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |