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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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