Xen users - Jun 2008 - Release 0.9.10 of GPL PV Drivers for Windows

I''ve just uploaded 0.9.10 to http://www.meadowcourt.org/downloads

As a reminder, the wiki page is
http://wiki.xensource.com/xenwiki/XenWindowsGplPv

If you are upgrading from 0.9.9, you might have a problem with
xenshutdown. The install script stops the service but the process
doesn''t stop immediately so the installer can''t update it as
the file is
in use. Either kill shutdownmon using task manager, or just wait 10
seconds or so and hit retry. This may need further work... You
shouldn''t
have any other issues upgrading as nothing should take effect until a
reboot is done.

The xennet ''parameters'' (csum offload, large send offload)
should now
work properly.

The drivers are now (self-)signed, and the cert is included. The
installer will prompt you to install the cert but I''m not sure how
effective that will be... it''s a start anyway. If you are using Vista
or
2008, please let me know if this makes things any easier or harder for
you, or if there''s anything else I need to do in the installer.

In order for things to install without any warnings at all, the drivers
need to pass Windows Logo verification, which I have no experience with.
Apparently you put the drivers through a bunch of tests, submit the logs
from those tests to Microsoft, pay a fee, and either your drivers get
passed or they get failed, hopefully with some explanation.

James

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

On Tue, Jun 17, 2008 at 08:43:23PM +1000, James Harper
wrote:
> I''ve just uploaded 0.9.10 to http://www.meadowcourt.org/downloads
> 
> As a reminder, the wiki page is
> http://wiki.xensource.com/xenwiki/XenWindowsGplPv
> 
> If you are upgrading from 0.9.9, you might have a problem with
> xenshutdown. The install script stops the service but the process
> doesn''t stop immediately so the installer can''t update it
as the file is
> in use. Either kill shutdownmon using task manager, or just wait 10
> seconds or so and hit retry. This may need further work... You
shouldn''t
> have any other issues upgrading as nothing should take effect until a
> reboot is done.
> 
> The xennet ''parameters'' (csum offload, large send
offload) should now
> work properly.
> 
Hi!

Have you thought about adding jumbo frame support (mtu 9000) ? 

There was some discussion about this earlier, but I guess there was no
conclusion.. obviously this feature needs configuration on dom0 too
(vif,bridge,peth).

-- Pasi

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

> 
> Hi!
> 
> Have you thought about adding jumbo frame support (mtu 9000) ?
> 
> There was some discussion about this earlier, but I guess there was no
> conclusion.. obviously this feature needs configuration on dom0 too
> (vif,bridge,peth).
> 
Yes I''ve thought about it, but I don''t think it''s
supported by netback so there''s not a lot I can do. I think some
changes need to be made so that netback and netfront/gplpv can tell each other
the MTU in use.

James

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

On Tue, Jun 17, 2008 at 09:07:23PM +1000, James Harper
wrote:
> > 
> > Hi!
> > 
> > Have you thought about adding jumbo frame support (mtu 9000) ?
> > 
> > There was some discussion about this earlier, but I guess there was no
> > conclusion.. obviously this feature needs configuration on dom0 too
> > (vif,bridge,peth).
> > 
> 
> Yes I''ve thought about it, but I don''t think
it''s supported by netback
> so there''s not a lot I can do. I think some changes need to be
made so
> that netback and netfront/gplpv can tell each other the MTU in use.
> 
Hmm.. OK. 

Somehow I thought some Xen implementation (Citrix XenServer or VirtualIron)
supported jumbos.. but I''m not sure about that. I''d have to
check again.

Does someone else have more information about this? 

-- Pasi

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

On 17/6/08 13:28, "Pasi Kärkkäinen" <pasik@iki.fi> wrote:
>>> There was some discussion about this earlier, but I guess there was
no
>>> conclusion.. obviously this feature needs configuration on dom0 too
>>> (vif,bridge,peth).
>>> 
>> 
>> Yes I''ve thought about it, but I don''t think
it''s supported by netback
>> so there''s not a lot I can do. I think some changes need to be
made so
>> that netback and netfront/gplpv can tell each other the MTU in use.
So long as you advertise feature-sg in xenstore then netback will allow the
mtu to be increased to jumbo sizes. This doesn''t happen automatically
-- the
user will need to increase mtu both in the vif inside the guest and on the
vif exposed in dom0. But apart from that it will work!

 -- Keir



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

The certification path is broken here, we need the cert of 
meadowcourt.org which has signed yours.

Florian
James Harper schrieb:
> I''ve just uploaded 0.9.10 to http://www.meadowcourt.org/downloads
> 
> As a reminder, the wiki page is
> http://wiki.xensource.com/xenwiki/XenWindowsGplPv
> 
> If you are upgrading from 0.9.9, you might have a problem with
> xenshutdown. The install script stops the service but the process
> doesn''t stop immediately so the installer can''t update it
as the file is
> in use. Either kill shutdownmon using task manager, or just wait 10
> seconds or so and hit retry. This may need further work... You
shouldn''t
> have any other issues upgrading as nothing should take effect until a
> reboot is done.
> 
> The xennet ''parameters'' (csum offload, large send
offload) should now
> work properly.
> 
> The drivers are now (self-)signed, and the cert is included. The
> installer will prompt you to install the cert but I''m not sure how
> effective that will be... it''s a start anyway. If you are using
Vista or
> 2008, please let me know if this makes things any easier or harder for
> you, or if there''s anything else I need to do in the installer.
> 
> In order for things to install without any warnings at all, the drivers
> need to pass Windows Logo verification, which I have no experience with.
> Apparently you put the drivers through a bunch of tests, submit the logs
> from those tests to Microsoft, pay a fee, and either your drivers get
> passed or they get failed, hopefully with some explanation.
> 
> James
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
> 


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

So in detail,
You have signed the stuff with meadowcourt.org which is signed by a cert 
of James Harper (is missing) and i assume this is issued by JamesXenCert 
(the cert in the pack)

Florian

Florian Manschwetus schrieb:
> The certification path is broken here, we need the cert of 
> meadowcourt.org which has signed yours.
> 
> Florian
> James Harper schrieb:
>> I''ve just uploaded 0.9.10 to
http://www.meadowcourt.org/downloads
>>
>> As a reminder, the wiki page is
>> http://wiki.xensource.com/xenwiki/XenWindowsGplPv
>>
>> If you are upgrading from 0.9.9, you might have a problem with
>> xenshutdown. The install script stops the service but the process
>> doesn''t stop immediately so the installer can''t
update it as the file is
>> in use. Either kill shutdownmon using task manager, or just wait 10
>> seconds or so and hit retry. This may need further work... You
shouldn''t
>> have any other issues upgrading as nothing should take effect until a
>> reboot is done.
>>
>> The xennet ''parameters'' (csum offload, large send
offload) should now
>> work properly.
>>
>> The drivers are now (self-)signed, and the cert is included. The
>> installer will prompt you to install the cert but I''m not sure
how
>> effective that will be... it''s a start anyway. If you are
using Vista or
>> 2008, please let me know if this makes things any easier or harder for
>> you, or if there''s anything else I need to do in the
installer.
>>
>> In order for things to install without any warnings at all, the drivers
>> need to pass Windows Logo verification, which I have no experience
with.
>> Apparently you put the drivers through a bunch of tests, submit the
logs
>> from those tests to Microsoft, pay a fee, and either your drivers get
>> passed or they get failed, hopefully with some explanation.
>>
>> James
>>
>> _______________________________________________
>> Xen-users mailing list
>> Xen-users@lists.xensource.com
>> http://lists.xensource.com/xen-users
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users


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

On Tuesday June 17 2008 06:43:23 am James Harper wrote:
> The xennet ''parameters'' (csum offload, large send
offload) should now
> work properly.
The xennet performance continues to improve.

for 0.9.9:
For a tcp test, ''iperf-1.7.0 -c dom0-name -t 60 -r'':

domu->dom0: 34 Mb/s
dom0->domu: 89 Mb/s

for 0.9.10:
For a tcp test, ''iperf-1.7.0 -c dom0-name -t 60 -r'':

domu->dom0: 37.5 Mb/s (better)
dom0->domu: 101 Mb/s (wow!)

While I would love it if the two directions were more equal, it''s
definitely
better for the download speeds to be better than the upload if I can only 
pick one ;-)

(Playing with all combinations of csum and lso off and on resulted in minor 
differences.)

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

> for 0.9.10:
> For a tcp test, ''iperf-1.7.0 -c dom0-name -t 60 -r'':
> 
> domu->dom0: 37.5 Mb/s (better)
> dom0->domu: 101 Mb/s (wow!)
> 
> While I would love it if the two directions were more equal, it''s
> definitely
> better for the download speeds to be better than the upload if I can
only
> pick one ;-)
> 
> (Playing with all combinations of csum and lso off and on resulted in
> minor differences.)
Off the top of my head, here are a list of reasons why performance might
not be all that it could be:

1. Linux supports Large Send and Large Receive (for when a Large Send
packet doesn''t get routed out of physical hardware). Windows can do
Large Send but cannot handle Large Receive, so I have to fake it by
splitting up the large packet into smaller ones and re-calculating
checksums.

2. Windows seems to only ever give me one packet in its
''SendPackets''
routine, which will obviously result in higher per-packet overheads than
if it could batch them (eg we potentially have to ''notify''
dom0 of a new
packet each time instead of having to batch them). Large Send may lessen
that problem a bit though.

3. We don''t try and do any interrupt moderation or anything.

4. We try and be a bit conservative with resources (eg packet buffers
etc).

So there is a chance of getting a bit more performance out of it yet...

James



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

James Harper schreef:
> So there is a chance of getting a bit more performance out of it yet...
>   
I hope so, because that''s the only reason it''s not production
ready yet.
The disk I/O is already very impressive (as I stated before) and it 
seems like the last 0.9.10 version even outperforms its predecessor. So 
don''t get me wrong, I''m very pleased and thankful for your
efforts, but
fixing the network performance issue(''s) would be great. Or at least 
boost it a bit ;-)

Joost

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

> 
> So in detail,
> You have signed the stuff with meadowcourt.org which is signed by a cert
> of James Harper (is missing) and i assume this is issued by JamesXenCert
> (the cert in the pack)
> 
Not quite, I just goofed. Two similar cert names in my store and I selected
the wrong one.

James


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

James Harper schrieb:
>> So in detail,
>> You have signed the stuff with meadowcourt.org which is signed by a
cert
>> of James Harper (is missing) and i assume this is issued by
JamesXenCert
>> (the cert in the pack)
>>
> 
> Not quite, I just goofed. Two similar cert names in my store and I selected
> the wrong one.
> 
> James
Could you upload a corrected version?

Florian
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users


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

> >
> > Not quite, I just goofed. Two similar cert names in my store and I
> selected
> > the wrong one.
> >
> > James
> Could you upload a corrected version?
> 
Just uploaded 0.9.11-pre4 which includes the cert. In case you saw that
email but actually wanted just the cert to make 0.9.10 work, I''ve
attached
it to this email.

James



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

> 
> So long as you advertise feature-sg in xenstore then netback will allow
> the
> mtu to be increased to jumbo sizes. This doesn''t happen
automatically --
> the
> user will need to increase mtu both in the vif inside the guest and on the
> vif exposed in dom0. But apart from that it will work!
> 
Well then it may actually ''just work'' in the windows drivers.
The MTU is settable in the normal way for a windows network driver (although
I''ve never tested it). If you do test it please let me know the
outcome.

Keir: Have you ever considered having the back end publish its MTU to the
frontend, so the two can be kept in sync?

James

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

On 22/6/08 12:08, "James Harper" <james.harper@bendigoit.com.au>
wrote:
>> So long as you advertise feature-sg in xenstore then netback will allow
>> the
>> mtu to be increased to jumbo sizes. This doesn''t happen
automatically --
>> the
>> user will need to increase mtu both in the vif inside the guest and on
the
>> vif exposed in dom0. But apart from that it will work!
>> 
> 
> Well then it may actually ''just work'' in the windows
drivers. The MTU is
> settable in the normal way for a windows network driver (although
I''ve never
> tested it). If you do test it please let me know the outcome.
> 
> Keir: Have you ever considered having the back end publish its MTU to the
> frontend, so the two can be kept in sync?
Should the backend control the frontend in this respect, or vice versa?

 -- Keir



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

> > Keir: Have you ever considered having the back end publish its MTU to
> the
> > frontend, so the two can be kept in sync?
> 
> Should the backend control the frontend in this respect, or vice versa?
> 
I''d thought about this. For a bridged setup, Dom0 needs to
''control'' the MTU setting as it needs to match the other
devices on the bridge. For a routed setup, it might actually make more sense for
DomU to control it, although with GSO it probably doesn''t matter so
much what the MTU actually is, and probably still makes more sense for Dom0 to
be in control.

Some possibilities:

#1. Specify the absolute MTU in the vif config file, which gets written to
xenstore. DomU would set its MTU to that.

#2. Specify a minimum and maximum MTU value for each vif in the config. For a
bridged interface they would be set the same. For a routed interface they could
be something like min=1500, max=9000. DomU would default to the closest MTU to
1500 that was within the range allowed by Dom0 (for compatibility, or maybe it
doesn''t matter...)

#1 is simple but less flexible. #2 would require the ability to change
MTU''s on the fly, which means some sort of communication channel would
need to be set up over and above the current ''state'' thing.
More flexibility but I have to wonder if that flexibility is needed...

Are there any situations you can think of where a DomU would be unhappy with the
MTU it is given, and that making a change to the config file to correct it would
not be an acceptable solution?
>From my understanding of the linux side of things, the netback driver would
just need to write any changes to the MTU to xenstore (if the frontend is not
connected), or fail to make the changes (if the fronted is connected).
I''m not sure if a linux kernel driver can control its MTU, although I
assume it can. On the windows side of things, the kernel driver does have
complete control over the MTU, although it does involve a remove and re-add of
the interface to change it.

James


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