|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] RFC: [0/2] Remove netloop by lazy copying in netback
> > Yep, the approach is similar, but I think having the > 'permanent' grants mechanism is probably a bit more flexible > for managing the header fragments. > Not sure why it would be more flexible. Do you mean dealing with headers that are in fragments? If headers are in fragments they will be linearized when copied into the shared header area by netfront. Also, it seems to me that having a fixed set of pages at initialization that never change is easier to manage. I probably did not understand you correctly... > It would be good if you could post your patch as it has > relevance to what Herbert is currently working on. > Ok. Here are the patches. A few disclaimers. They were not intended to be distributed as is, so there may be some cleanups/optimizations needed, although they were tested on an older version and used to work. They also do not apply cleanly to the current xen-unstable. I am not sure they will be very helpful to Herbert, but since you asked, here they are. > BTW: I'm pretty convinced its time to redefine the net ring > format to ensure each fragment has an id, flags, grant, > offset and length fields. > Things are just getting messy with the current format. I agree that we will need a new format soon, but I am not sure I understood your concerns above. Currently all fragments do have an id, flag, grant, offset and length fields. Maybe you mean that we need a better way to represent multiple fragments belonging to the same packet. Any way, the performance analysis that I am doing may indicate that we might need some architectural changes on the device model. I would like to discuss this before we settle on a format. I am trying to get some data in time for the summit, but I am racing the clock... Regards Renato ======================== Patches tx_header_copy: Create and uses set of shared pages between netfront and netback to copy packet headers on network TX path. tx_lazy_map: Do not create a host mapping for packet fragments Tx_handle_page_fault: Handle page fault caused by dom0 trying to access unmapped skb fragment. Creates the mapping in that case > > Best, > Ian > > > > Attachment:
tx_header_copy-11760.patch Attachment:
tx_lazy_map-11760.patch Attachment:
tx_handle_page_fault.patch _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |