reasons/requirements for some of patches/linux-2.6.16.29/*

reasons/requirements for some of patches/linux-2.6.16.29/*

[Jan Beulich]

Could anyone give a description (and reason it is needed for Xen, if that's
not obvious from the description) for each of

blktap-aio-16_03_06.patch
net-gso-*.patch
tpm_plugin_2.6.17.patch 

Thanks a lot, Jan

Re: reasons/requirements for some of patches/linux-2.6.16.29/*

[Keir Fraser]

On 6/10/06 8:25 am, "Jan Beulich" <jbeulich@novell.com> wrote:

> Could anyone give a description (and reason it is needed for Xen, if that's
> not obvious from the description) for each of
> 
> blktap-aio-16_03_06.patch

Not sure. Andrew Warfield or Julian Chesterfield probably will know. I would
guess it's probably a backport of AIO changes from a more recent kernel, but
I'm not certain about that.

> net-gso-*.patch

Backport of GSO patches from 2.6.17,18,... Done by Herbert Xu as part of his
big netfront/back reworking and upgrade. This will mostly go away when we
upgrade to 2.6.18.

> tpm_plugin_2.6.17.patch

IBM-requested backport of TPM changes in 2.6.17. This will go away when we
upgrade to 2.6.18.

 -- Keir

Re: reasons/requirements for some of patches/linux-2.6.16.29/*

[Jan Beulich]

>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 06.10.06 09:25 >>>
>On 6/10/06 8:25 am, "Jan Beulich" <jbeulich@novell.com> wrote:
>
>> Could anyone give a description (and reason it is needed for Xen, if that's
>> not obvious from the description) for each of
>> 
>> blktap-aio-16_03_06.patch
>
>Not sure. Andrew Warfield or Julian Chesterfield probably will know. I would
>guess it's probably a backport of AIO changes from a more recent kernel, but
>I'm not certain about that.

It's certainly not a backport (i.e. still needed in almost unchanged form in 2.6.18).

>> net-gso-*.patch
>
>Backport of GSO patches from 2.6.17,18,... Done by Herbert Xu as part of his
>big netfront/back reworking and upgrade. This will mostly go away when we
>upgrade to 2.6.18.

I understand that. But what I need is an understanding of why Xen needs this
right away.

>> tpm_plugin_2.6.17.patch
>
>IBM-requested backport of TPM changes in 2.6.17. This will go away when we
>upgrade to 2.6.18.

Likewise here.

Jan

Re: reasons/requirements for some of patches/linux-2.6.16.29/*

[Keir Fraser]

On 6/10/06 08:51, "Jan Beulich" <jbeulich@novell.com> wrote:

>> Backport of GSO patches from 2.6.17,18,... Done by Herbert Xu as part of his
>> big netfront/back reworking and upgrade. This will mostly go away when we
>> upgrade to 2.6.18.
> 
> I understand that. But what I need is an understanding of why Xen needs this
> right away.

It doesn't. Netfront at least should compile without it. It would be
similarly easy to make netback do so too if it doesn't already.

>>> tpm_plugin_2.6.17.patch
>> 
>> IBM-requested backport of TPM changes in 2.6.17. This will go away when we
>> upgrade to 2.6.18.
> 
> Likewise here.

I don't know if Xen-specific drivers in the sparse tree depend on that
patch. Stefan Berger will know better than me (cc'ed).

 -- Keir

Re: reasons/requirements for some of patches/linux-2.6.16.29/*

[Daniel P. Berrange]

On Fri, Oct 06, 2006 at 08:51:28AM +0100, Jan Beulich wrote:
> >>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 06.10.06 09:25 >>>
> >On 6/10/06 8:25 am, "Jan Beulich" <jbeulich@novell.com> wrote:
> >
> >> Could anyone give a description (and reason it is needed for Xen, if that's
> >> not obvious from the description) for each of
> >> 
> >> blktap-aio-16_03_06.patch
> >
> >Not sure. Andrew Warfield or Julian Chesterfield probably will know. I would
> >guess it's probably a backport of AIO changes from a more recent kernel, but
> >I'm not certain about that.
> 
> It's certainly not a backport (i.e. still needed in almost unchanged form in 2.6.18).
> 
> >> net-gso-*.patch
> >
> >Backport of GSO patches from 2.6.17,18,... Done by Herbert Xu as part of his
> >big netfront/back reworking and upgrade. This will mostly go away when we
> >upgrade to 2.6.18.
> 
> I understand that. But what I need is an understanding of why Xen needs this
> right away.

A significant performance increase. Without it, DomU -> Dom0 networking is far 
less than baremetal wirespeed; With it, DomU -> Dom0 networking has parity
with baremetal wirespeed. Herbert's preso at the summit had a few more details

  http://xensource.com/files/summit_3/rdd-tso-xen.pdf

Regards,
Dan
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

Re: reasons/requirements for some of patches/linux-2.6.16.29/*

[Stefan Berger]

[-- Attachment #1.1: Type: text/plain, Size: 980 bytes --]

Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote on 10/06/2006 04:17:12 AM:

> On 6/10/06 08:51, "Jan Beulich" <jbeulich@novell.com> wrote:
> 
> >>> tpm_plugin_2.6.17.patch
> >> 
> >> IBM-requested backport of TPM changes in 2.6.17. This will go away 
when we
> >> upgrade to 2.6.18.
> > 
> > Likewise here.
> 
> I don't know if Xen-specific drivers in the sparse tree depend on that
> patch. Stefan Berger will know better than me (cc'ed).

Plain 2.6.16 gives the following function in tpm.c:

int              tpm_register_hardware(struct device *dev, struct 
tpm_vendor_specific *entry)

2.6.17 offers the following signature:

struct tpm_chip *tpm_register_hardware(struct device *dev, const struct 
tpm_vendor_specific *entry)

I adopted this from 2.6.17 since I needed to have access to the tpm_chip 
structure where I could store other driver-specific information in. Of 
course all plugin drivers use this function and therefore the 
tpm_plugin_2.6.17.patch exists.

  Stefan

[-- Attachment #1.2: Type: text/html, Size: 3029 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: reasons/requirements for some of patches/linux-2.6.16.29/*

[Andrew Warfield]

> > Could anyone give a description (and reason it is needed for Xen, if that's
> > not obvious from the description) for each of
> >
> > blktap-aio-16_03_06.patch
>
> Not sure. Andrew Warfield or Julian Chesterfield probably will know. I would
> guess it's probably a backport of AIO changes from a more recent kernel, but
> I'm not certain about that.

The patch allows polling of aio and non-aio file descriptors through a
single call.  It's a stopgap that was sent to the aio devel list and
is there in anticipation of a solution for mixed polling in linux.

The old approach was to have a separate thread to call aio_getevents
and signal that to the main poll loop through a pipe -- it's no less
ugly, but keeps changes to user space at a cost in performance.

a.

Re: reasons/requirements for some of patches/linux-2.6.16.29/*

[Stephen C. Tweedie]

Hi,

On Fri, 2006-10-06 at 08:25 +0100, Jan Beulich wrote:
> Could anyone give a description (and reason it is needed for Xen, if that's
> not obvious from the description) for each of
> 
> blktap-aio-16_03_06.patch

The blktap userland server (tapdisk) submits IO requests via kernel AIO,
but also waits for network/evtchn events via file descriptors.  And
alas, the kernel has no way to wait for AIO and fd wakeups in a single
syscall.

This patch implements aio-for-poll --- it's a new core kernel ABI which
allows a temporary fd to be associated with an AIO IO context, so you
can wait on AIO and normal fds via a single select() call.  But this ABI
has been vetoed upstream.

Upstream has given initial approval to an alternative means whereby
instead of submitting a poll() for AIO, you submit an AIO request for
poll.  Then, io_getevents() can wait for both fd and AIO activity.  But
that functionality is still not upstream.

We did not want to include the non-approved AIO+poll mechanism in our
own Fedora kernels, so as a workaround, I've coded up a simple patch
which makes tapdisk spawn a separate thread for AIO events, and return
wakeups via a pipe fd to the main event loop when AIO arrives.  That
works fine as a temporary measure to allow us to ship blktap without the
AIO/poll stuff resolved upstream; but longer term, Jeff Moyer has been
talking to the AIO people to get epoll-for-AIO merged.  I'm not sure of
the status of that work though, it may well have stalled.

I can post the AIO-thread patch here if anyone's interested; I didn't
post it as part of my recent blktap changes because (a) Xen upstream
doesn't need it, it carries the aio-for-poll patch instead; and (b) the
_right_ answer for Xen is eventually to use an upstream-blessed poll-
for-aio patch instead.

Cheers,
 Stephen

Re: reasons/requirements for some of patches/linux-2.6.16.29/*

[Herbert Xu]

Jan Beulich <jbeulich@novell.com> wrote:
>
> It's certainly not a backport (i.e. still needed in almost unchanged form in 2.6.18).
> 
>>> net-gso-*.patch
>>
>>Backport of GSO patches from 2.6.17,18,... Done by Herbert Xu as part of his
>>big netfront/back reworking and upgrade. This will mostly go away when we
>>upgrade to 2.6.18.

Because TSO is enabled by default in netfront.  Without this you won't
have external communications if your physical NIC driver does not support
TSO.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt