Re: [owl-users] vlan support broken?

From: Solar Designer <solar_at_private>
Date: Sat, 5 Mar 2011 21:57:19 +0300
On Sat, Mar 05, 2011 at 04:39:37PM +0100, Piotr Meyer wrote:
> Uff. I made more tests, then I repeat them and careful wrote results, and
> now I know that:
> 
> 1. Default selected eepro100 doesn't support vlans (it's nothing new,
>    but should be noticed) - eepro100 should be disabled in favour e100.

Thanks.  Yes, we may change the default driver for this NIC type.

> 2. Without Owl patch (taken from public repo) all works fine: transfers 
>    via tg3 and e100 and _pings_ from machine to remote hosts.
>    Tested on 2.6.18 with OpenVZ patches.
> 
> 3. After applying Owl patch transfers on tg3 and e100 works as expected,
>    but pinging from server to remote hosts works only, when selected
>    packetsize (-s) is lesser than 1473 bytes.

That's curious.  Yes, I confirm that our non-raw ICMP socket mode of
ping only works when the MTU would not be exceeded.  That is, on a clean
install of Owl-current 2011/02/12, ping to external hosts over MTU 1500
Ethernet only works for sizes up to 1472 bytes (which translates to
exactly 1500 bytes with IP and ICMP headers).  1473+ doesn't work
("packet loss").  However, when I do:

sysctl -w net.ipv4.ping_group_range='1 0'

which disables our ICMP sockets, and then run ping as root, larger sizes
work (with IP fragmentation).

Vasiliy - can you please take a look and see if it's an intentional
limitation or if it's something to be fixed in the code?  Maybe ask
Pavel on owl-dev.

I did my testing (above) with no VLANs involved on the Owl system.

> In my previous posts I made incorrect assumptions because of use ping
> command for all tests.

Oh, do you normally use ping with large packets?  I mean, it definitely
makes sense to test large packet pings in some cases, and you've even
identified a shortcoming that we might want to fix, but "by default"
most people run ping without raising its packet size.  So I am a bit
surprised that this managed to lead you to the wrong conclusions.

Thanks again,

Alexander
Received on Sat Mar 05 2011 - 10:57:19 PST

This archive was generated by hypermail 2.2.0 : Sat Mar 05 2011 - 10:57:33 PST