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

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.

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