jumbo frames

jumbo frames

[Kip Macy]

What is the status of jumbo frame support in dom0 and domU? Unless
something has changed I know it isn't supported in domU, but shouldn't
it just work in dom0?


                     -Kip

Re: jumbo frames

[Keir Fraser]

On 11 May 2005, at 01:14, Kip Macy wrote:

> What is the status of jumbo frame support in dom0 and domU? Unless
> something has changed I know it isn't supported in domU, but shouldn't
> it just work in dom0?

I think it'll just work, but it's untested. If the jumbo area spans 
multiple memory pages then it needs to be allocated with something like 
dma_alloc_coherent, or be represented by a fragmented skbuff. (i.e., 
hopefully the network stack and drivers don't assume that kmalloc() 
always return physically contiguous memory extents).

  -- Keir

Re: jumbo frames

[Kip Macy]

On Wed, 11 May 2005, Keir Fraser wrote:

> 
> On 11 May 2005, at 01:14, Kip Macy wrote:
> 
> > What is the status of jumbo frame support in dom0 and domU? Unless
> > something has changed I know it isn't supported in domU, but shouldn't
> > it just work in dom0?
> 
> I think it'll just work, but it's untested. If the jumbo area spans 
> multiple memory pages then it needs to be allocated with something like 
> dma_alloc_coherent, or be represented by a fragmented skbuff. (i.e., 
> hopefully the network stack and drivers don't assume that kmalloc() 
> always return physically contiguous memory extents).
> 

What all would need to change to support it for domUs?

				-Kip

Re: jumbo frames

[Keir Fraser]

On 11 May 2005, at 07:27, Kip Macy wrote:

>>> What is the status of jumbo frame support in dom0 and domU? Unless
>>> something has changed I know it isn't supported in domU, but 
>>> shouldn't
>>> it just work in dom0?
>>
>> I think it'll just work, but it's untested. If the jumbo area spans
>> multiple memory pages then it needs to be allocated with something 
>> like
>> dma_alloc_coherent, or be represented by a fragmented skbuff. (i.e.,
>> hopefully the network stack and drivers don't assume that kmalloc()
>> always return physically contiguous memory extents).
>>
>
> What all would need to change to support it for domUs?

We need scatter-gather support on the device channel, and the frontend 
and backend both need to know how to queue and dequeue fragmented 
network buffers.

  -- Keir

Re: jumbo frames

[Kip Macy]

> >
> > What all would need to change to support it for domUs?
> 
> We need scatter-gather support on the device channel, and the frontend
> and backend both need to know how to queue and dequeue fragmented
> network buffers.
> 
>   -- Keir

Is it anywhere on the roadmap?

      -Kip

RE: jumbo frames

[Ian Pratt]

 
> > > What all would need to change to support it for domUs?
> > 
> > We need scatter-gather support on the device channel, and 
> the frontend 
> > and backend both need to know how to queue and dequeue fragmented 
> > network buffers.
> > 
> >   -- Keir
> 
> Is it anywhere on the roadmap?

Post 3.0. Having it working in dom0 is good enough for iSCSI.

Unfortunately, many of the drivers use pci_map_page even for jumbo
frames, which is defined as dma_map_page which uses page_to_phys and
assumes that only a single page is being mapped. 

I think we'll need to create another cache for jumbo frames and bless
them with xen_contig_memory in the ctor function. Hmm, I'm not sure that
ctor functions can return failure, though...

Ian 

Re: jumbo frames

[Jon Mason]

On Wednesday 11 May 2005 01:21 am, Keir Fraser wrote:
> On 11 May 2005, at 01:14, Kip Macy wrote:
> > What is the status of jumbo frame support in dom0 and domU? Unless
> > something has changed I know it isn't supported in domU, but shouldn't
> > it just work in dom0?
>
> I think it'll just work, but it's untested. If the jumbo area spans
> multiple memory pages then it needs to be allocated with something like
> dma_alloc_coherent, or be represented by a fragmented skbuff. (i.e.,
> hopefully the network stack and drivers don't assume that kmalloc()
> always return physically contiguous memory extents).

I've actually wanted to look into this for a while.  

It seems to me that MTUs of ~4000 (1 page) should be fairly trivial to 
impliment, and should boost performance significantly (with no extra cost as 
we are using the full page anyway).  

Kip, if you don't want to do it, I will ;-)

Thanks,
Jon  

Re: jumbo frames

[Kip Macy]

> It seems to me that MTUs of ~4000 (1 page) should be fairly trivial to
> impliment, and should boost performance significantly (with no extra cost as
> we are using the full page anyway).
> 
> Kip, if you don't want to do it, I will ;-)

That would be awesome.

Let me know if you want some extra testing done for any patches.

          -Kip