3.0.4 (and earlier): skbuff_ctor() use of xen_create_contiguous_region()

3.0.4 (and earlier): skbuff_ctor() use of xen_create_contiguous_region()

[Jan Beulich]

While I realize that this is gone from -unstable, I'd still like to understand what
the purpose of using xen_create_contiguous_region() in skbuff_ctor() was,
and specifically what consequences I am to expect when this call fails.

Thanks, Jan

Re: 3.0.4 (and earlier): skbuff_ctor() use of xen_create_contiguous_region()

[David Edmondson]

On Fri, Mar 09, 2007 at 12:17:39PM +0000, Jan Beulich wrote:
> While I realize that this is gone from -unstable, I'd still like to
> understand what the purpose of using xen_create_contiguous_region()
> in skbuff_ctor() was, and specifically what consequences I am to
> expect when this call fails.

So that a multi-page packet is physically contiguous when passed to
the NIC for transmit?

If it's not physically contiguous and the NIC hardware can't do
scatter gather then the driver has to re-allocate and copy.

dme.

Re: 3.0.4 (and earlier): skbuff_ctor() use of xen_create_contiguous_region()

[Jan Beulich]

>>> David Edmondson <dme@sun.com> 09.03.07 13:37 >>>
>On Fri, Mar 09, 2007 at 12:17:39PM +0000, Jan Beulich wrote:
>> While I realize that this is gone from -unstable, I'd still like to
>> understand what the purpose of using xen_create_contiguous_region()
>> in skbuff_ctor() was, and specifically what consequences I am to
>> expect when this call fails.
>
>So that a multi-page packet is physically contiguous when passed to
>the NIC for transmit?
>
>If it's not physically contiguous and the NIC hardware can't do
>scatter gather then the driver has to re-allocate and copy.

I understand that, but what I wanted clarification on is whether this is
only for performance, not for correctness (and performance would still
suffer if the allocation turns out to be beyond the physical reach of the
particular NIC).

Jan

Re: 3.0.4 (and earlier): skbuff_ctor() use of xen_create_contiguous_region()

[David Edmondson]

On Fri, Mar 09, 2007 at 12:45:27PM +0000, Jan Beulich wrote:
> I understand that, but what I wanted clarification on is whether this is
> only for performance, not for correctness (and performance would still
> suffer if the allocation turns out to be beyond the physical reach of the
> particular NIC).

For performance, I believe (though it's difficult to know with so many
Linux drivers).  On Solaris the DDI DMA framework would "sort it all
out"...

dme.

Re: 3.0.4 (and earlier): skbuff_ctor() use of xen_create_contiguous_region()

[Keir Fraser]

On 9/3/07 12:45, "Jan Beulich" <jbeulich@novell.com> wrote:

> I understand that, but what I wanted clarification on is whether this is
> only for performance, not for correctness (and performance would still
> suffer if the allocation turns out to be beyond the physical reach of the
> particular NIC).

Yes, and yes (specifically primarily the jumbo-frame receive case, as
described in my previous email). Thus you may want to consider keeping the
patch in your own kernel.

 -- Keir

Re: 3.0.4 (and earlier): skbuff_ctor() use of xen_create_contiguous_region()

[Keir Fraser]

On 9/3/07 12:37, "David Edmondson" <dme@sun.com> wrote:

> So that a multi-page packet is physically contiguous when passed to
> the NIC for transmit?
> 
> If it's not physically contiguous and the NIC hardware can't do
> scatter gather then the driver has to re-allocate and copy.

Yes, it was originally intended for drivers that would do dma_map_single()
on the whole multi-page network buffer (for receive and/or transmit
buffers). Of course we still potentially have this issue and will now end up
falling back to swiotlb at the time of the dma_map_single() call. It's only
(usually) an issue for jumbo-frame systems since kmalloc() will not usually
return page-straddling allocations for sub-page requests. Also the custom
allocator did not help the transmit-from-domU case since jumbo packets are
always fragged across netfront/netback, and then many drivers will handle
fragged packets efficiently. But it could have helped the receive-to-domU
case by avoiding an extra copy, as most drivers want to allocate a single
contiguous buffer for jumbo frames.

 -- Keir