WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [0/5] [NET]: Add TSO support


On 28 Jun 2006, at 15:02, Herbert Xu wrote:

2. The new 'wire format' with netif_tx_extra: I placed the GSO fields
inside a struct inside a union, so we can extend the union with other
extra-info types in future. I hope that's okay and in line with what
you intended.

Actually, the idea is to add new fields after the existing fields so
I don't think a union is a good fit here.  The reason is that the new
fields will likely be used in conjunction with GSO.  In particular, I'm
thinking of the checksum offset/header offset.

Adding new fields on the end of the existing structure is limiting. Maybe we could chain extra info structures by declaring NETTXF_extra_info in the leading request, then have a sequence of netif_tx_extras, each of which is a discriminated union (so a NETEXTRA_* type field, a flag indicating if this is the last extra-info for this packet, plus a union)?


3. Wire format again: we need some extra documentation and info in
netif.h for the new GSO fields. Currently they conveniently directly
correspond to fields in a Linux skbuff: you read them out in netfront
and write them straight back in netback. That's fine for Linux for now,
but not so good for other OSes, nor potentially if the Linux GSO
internals change later.

Well I think things like TSO (and even more so with GSO) are highly
OS-specific so porting them to other paravirt OSes are always going to
be hard.

Many NICs support TSO so there should be support in network stacks other than Linux. What about *BSD, Solaris, and Windows?

The way I see it these are simply add-on features that you can enable
to get that extra bit out of your Xen performance. So it is not required
for your system to function.  Therefore other OSes that do not have
TSO/GSO can simply elect to not use it.

They may not have GSO but they might well have TSO and we should make it possible to interface to netback using it.

* Provide translation layers in the netfront/netback if the interface
change does not require new information to be exchanged.

* Adding new feature bits/request flags to indicate that new information is required. Older guests/hosts would simply not do TSO with incompatible
new hosts/guests.

TSO isn't that complicated. I think we should be able to come up with an inter-domain format that we don't have to break for older guests down the line.

If Linux ever does make an incompatible change (which believe me I will
do my best to prevent), having those values defined here are not really
going to help people notice the change or provide compatibility.

But if you really want these values, I can add them.

Yes, we want them, and explicit code in netfront/netback to convert between Linux gso types and 'wire' gso types. Even if they are initially the same!

Another question: why are gso_size and gso_segs both required? Surely those, plus the overall request size, are redundant. e.g., shouldn't gso_segs = tot_size / gso_size (rounded up)?

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel