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