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
pgp7zd6ZeYjtm.pgp
Description: PGP signature
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home