Hi,
I made some tests about ethernet padding ( in my dummy works:
an expected behavior from ethernet 10/100 on-wire, that needs at
least 60 bytes of data to be able to CRC and the NIC chipset has the
job of fullfill the packet if it is smaller than this- padding ) and
I notice a behavior that is not expected (at least for me).
My setup is a Centos 5.1/Xen (3.0.3) in a bridge network
configuration and I''ve got the following results:
>>> Ethernet Padding Sender / Receiver Matrix <<<
\RECEIVER | Dom0 vif | FullV_DomU_2 | ParaV_DomU_2
| SMP_ParaV_DomU_2
SENDER/
Dom0 vif.......................| No (OK) | Yes (OK) | No (NOK)
| No (NOK)
FullV_DomU................| No (NOK) | Yes (OK) | No (NOK) | No (NOK)
ParaV_DomU..............| No (NOK) | Yes (OK) | No (NOK) | No (NOK)
SMP_ParaV_DomU...| No (NOK) | Yes (OK) | No (NOK) | No (NOK)
The results shows that only FullVirtualization do padding,
and only when receives a packet (not when send it).
You could ask "why padding if you dont have a physical
transport?". If you are playing with some L2 protocol (like AoE),
this behavior do impact.
From results, we conclude that is not possible, for
example, to export AoE disks from Dom0 and other Paravirtualized
guests (AoE blade server verifies if the packet has a minimal size -
60 bytes minimal ethernet on-wire packet). I do not known if another
layer2 protocols has the same problem, but I think that is a expected
feature that a virtual NIC works as a physical one..
To have a consistent behavior, everybody should do
ethernet padding (my expected behavior), or no one should do this.
Make sense? I changed the AoE initiator vblade to not
discard packets "not padded" (very simple change, but I still dont
have an answer why the padding limit was there), but I appreciate if
someone could give more 2 cents for this issue.
Cheers
Marcelo Messa
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
> > I made some tests about ethernet padding ( in my dummy works: > an expected behavior from ethernet 10/100 on-wire, that needs at > least 60 bytes of data to be able to CRC and the NIC chipset has the > job of fullfill the packet if it is smaller than this- padding ) and > I notice a behavior that is not expected (at least for me). >Maybe not relevant to you problem, but I have a router which uses the ''via_rhine'' linux Ethernet driver, and it simply doesn''t bother padding packets when sending them out on the wire. The Cisco switch that it is connected to reflects those packets in the ''runt frames'' counter, but otherwise isn''t bothered. Nothing else on the network appears to be bothered either. I''ve raised the problem with the author of the driver, the linux kernel mailing list, and even submitted a patch, but nobody seems to care. (it may actually be fixed by now, I haven''t checked as the only problem it appears to cause is the counter incrementing on the cisco router) I think that the minimum frame size was only really imported on single duplex unswitched networks (eg a ''hub'' or 10base[25]), where you had to be absolutely sure that if you were up one end of the wire, you''d be able to sense a device transmitting from the other end of the wire whilst you were still transmitting your packet, so that you could detect the collision. If you had finished your packet (because it was too short), then you''d not see the packet from the other end of the wire until you were idle again, and the packet would be lost. James _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users