Xen devel - Mar 2007 - 3.0.4 (and earlier): skbuff_ctor() use of xen_create_contiguous_region()

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

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

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.

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

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

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

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.

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

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


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

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


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