Re: Large performance regression with 6in4 tunnel (sit)

[Sven-Haegar Koch]

On Fri, 25 Nov 2016, Stephen Rothwell wrote:

> On Fri, 25 Nov 2016 10:18:12 +0800 Eli Cooper  wrote:
> >
> > Sounds like TSO/GSO packets are not properly segmented and therefore
> > dropped.
> > 
> > Could you first try turning off segmentation offloading for the tunnel
> > interface?
> > ethtool -K sit0 tso off gso off
> 
> On Thu, 24 Nov 2016 18:30:14 -0800 Eric Dumazet 
> >
> > You also could try to disable TSO and see if this makes a difference
> > 
> > ethtool -K sixtofour0 tso off
> 
> So turning off tso brings performance up to IPv4 levels ...
> 
> Thanks for that, it solves my immediate problem.

Somehow this problem description really reminds me of a report on 
netdev a bit ago, which the following patch fixed:

commit 9ee6c5dc816aa8256257f2cd4008a9291ec7e985
Author: Lance Richardson 
Date:   Wed Nov 2 16:36:17 2016 -0400

ipv4: allow local fragmentation in ip_finish_output_gso()

Some configurations (e.g. geneve interface with default
MTU of 1500 over an ethernet interface with 1500 MTU) result
in the transmission of packets that exceed the configured MTU.
While this should be considered to be a "bad" configuration,
it is still allowed and should not result in the sending
of packets that exceed the configured MTU.

Could this be related?

I suppose it would be difficult to test this patch on this machine?

c'ya
sven-haegar

-- 
Three may keep a secret, if two of them are dead.
- Ben F.

Re: Network drivers that don't suspend on interface down

[Sven-Haegar Koch]

On Wed, 20 Dec 2006, Dan Williams wrote:


If we define interface down as meaning that the device is powered down
and the radio switched off, then (b) and (c) would presumably just need
to ensure that the interface is downed. (a) is a slightly more special
case - if the switch disables the radio, I guess we then want the driver
to down the interface as well.


Correct.


In the (a) case, drivers should presumably refuse to bring the interface
up if the radio is disabled?


Right; the driver simply can't do anything about it, because the switch
is hardwired to the card and either the card's firmware takes care of
it, or the chipset takes care of it.  The driver has no say whatsoever
in the state of the card's radio for this case.  I tend to think this
case is on it's way out in the same way that fullmac cards are falling
out of favor (ie, do everything in software and save $$$), but they are
around and we need to support them.

In this case, down really does mean down too.  The driver cannot honor
requests to set SSID, frequency, etc, because it's simply not possible
at that time.


What do you mean with this exactly?
Should the user not be able to set these values, or should the driver not 
be able to activate them?


I think it is correct when the driver does not activate them, but I think 
the user should be able to configure them, have them stored inside 
cfg80211/the driver, and have them activated/used when uping the 
interface, or when the rfkill switch has been deactivated. Otherwise it 
will get impossible to boot with rfkill disabled, toggle the switch later 
on and have everything working.


And another side to this:
if a disabled rfkill switch downs the interface (opposed to just 
disabling it but staying ifconfig up) - what happens to the ip config 
of this interface? What reconfigures the needed routes when a re-enabled 
rfkill switch reactivates the interface? Will manual route add and 
ifconfig statements be impossible and we'll get forced to use some crappy 
distri-scripts and daemons for it?


And third point just coming to my mind:
how is changing the mac address of the card supposed to work? Chaning it 
through ifconfig only works when the interface is downed, so the newly 
wanted mac address has to be saved somewhere before the interface is 
reenabled and reinitialized on the next ifconfig up.
(And I think it is an absolute requirement that NO packet with the 
old/default mac address may be sent into the air whatsoever)


c'ya
sven

--

The Internet treats censorship as a routing problem, and routes around it.
(John Gilmore on http://www.cygnus.com/~gnu/)
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc

[Sven-Haegar Koch]

On Thu, 2 Nov 2006, Jiri Benc wrote:


On Thu, 2 Nov 2006 14:18:15 +, Christoph Hellwig wrote:

This is not about the name that makes sense.  I think using ethX names
for wireless devices is utterly stupid, but it's what all current upstream
drivers do, and at least for WE compat we'll have to stick to it.


That's not true. Look at hostap or zd1201, for example. Also, ethX name
is not needed for WE compatibility. And because of various names used
by various drivers (madwifi uses ath0, for example) config scripts
don't depend on ethX name today anyway.


At least the ones used on my machines all do.
(Debian Sarge, Etch and Unstable)
The configfiles can be changed without problems to use any device name, 
but needing to edit various files just for a kernel update would inhibt me 
from just trying a new version until I really know I would not need to go 
back to the old version again.


(Switching wireless from eth1 to eth2 after copying the harddisk contents 
to a new laptop was work enough, but at least expected with a new machine 
and changed hardware)


c'ya
sven

--

The Internet treats censorship as a routing problem, and routes around it.
(John Gilmore on http://www.cygnus.com/~gnu/)
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html