[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGUzgdLyqett=78cVYYVWi=ZRE_Z4xgp8tB+jRyEeykcPxRjOQ@mail.gmail.com>
Date: Tue, 5 Mar 2013 17:22:05 +0100
From: Sebastian Pöhn <sebastian.poehn@...glemail.com>
To: Erik Hugne <erik.hugne@...csson.com>
Cc: netdev@...r.kernel.org, jon.maloy@...csson.com,
allan.stephens@...driver.com
Subject: Re: tipc: MTU discovery
I run a DLink DGE-528T (PCI-ID: 1186:4300). Kernel is 2.6.32
There is a dedicated VLAN sitting over the physical device.
I even made some similar observations in a VM environment but I think
this is even a more fragile setup.
Will install ethtool ...
On Tue, Mar 5, 2013 at 3:18 PM, Erik Hugne <erik.hugne@...csson.com> wrote:
> On Tue, Mar 05, 2013 at 01:43:29PM +0100, Sebastian Pöhn wrote:
>> State Messages larger than 1500 which as used for the MTU negotiation
>> do not appear in the TIPC stack. But I am able to seen them entering
>> the correct device.
>> Because of that no reply with the correct max_packet field set can be
>> send and the negotiation will always end up at 1.5k.
>>
>> So my questions are:
>> # Is TIPC meant to detect and use the MTU larger than 1.5k?
> Yes, it should probe and detect MTU's up to ~66k
>
>> # Why are the packets not passed to the TIPC stack?
> TIPC just registers itself as a handler for ETH_P_TIPC through
> dev_add_pack.
> If link mtu probes >1.5k are not passed to TIPC, it sounds to me that the
> NIC driver
> is to blame. What NIC type and kernel version are you running?
>
> Do you see any packet drops in ethtool statistics?
>
> //E
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists