[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
> 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...




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
Description: tx_header_copy-11760.patch

Attachment: tx_lazy_map-11760.patch
Description: tx_lazy_map-11760.patch

Attachment: tx_handle_page_fault.patch
Description: tx_handle_page_fault.patch

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.