Re: [Xen-users] NFS problems in guest

[Javier Guerra <javier@xxxxxxxxxxx>]

On Sunday 30 April 2006 1:18 pm, Birger Brunswiek wrote:
> I'm not sure why ip_conntract defragments but not refragments the packets
> it receives. Maybe it's not even supposed to refragment them and assumes
> the network device will ... but a bridge does not as it works on the
> ethernet layer.

ok, i think i got the spirit of the problem.  by nature, ip_conntrack have to 
work on defragmented packages. a bridge, OTOH, works at ethernet frame level; 
it doesn't care if those frames contain fragments or complete packets, as 
long as they're not longer than the MTU of any interface.

in a 'typical' router (IP level, no bridging), it's ok to defragment (even 
convenient most times), and any packet would be refragmented (if needed) on 
it's way out of the router.  for example, if you have a WAN interface with an 
MTU of 512, you might get a very fragmented packet, and after reassembly it 
might be 2000 bytes long (unlikely, but legal).  when the routing code sends 
it to a Ethernet LAN, it would have to split it into 1500-byte fragments.

when you do have a bridge, this is different; a 'real' bridge shouldn't see 
into the ethernet frames, and shouldn't modify the packages in any way.  all 
interfaces should have the same MTU, and there shouldn't be any problem.  but 
since ip_conntrack reassembles IP fragments, the bridge suddenly finds 
packets too big to handle, and has to drop them.

in most networks that's not a problem, since the protocol stack optimises it's 
packet length until they go all the way without fragmenting (end-to-end MTU 
discovery).  at the very least, this happens on TCP layers... but NFS uses 
UDP by default.

the NFS manpage says the rsize and wsize parameters are 1024 by default, but 
performance is improved using 8192.  of course, when using NFS over TCP, that 
means that almost all traffic would be on fragmented packets (since UDP 
doesn't fragment, the IP layer would).

so, an interesting test would be:

1) using NFS over UDP with big rsize/wsize parameters over a linux bridge with 
ip_conntrack and no Xen (i think i can do this test... maybe this wednesday)

2) trying NFS over TCP on a bridging Xen box

3) reducing rsize/wsize on the NFS client on a bridging Xen box.

if it's a linux networking issue, and not a Xen issue, case 1) should fail, 
and 2) and 3) should work.  it would be interesting to compare performance of 
2) and 3)....


-- 
Javier

Attachment: pgpFNPLMdJcPN.pgp
Description: PGP signature

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