lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 11 Nov 2014 10:34:57 +0100
From:	Michal Kubecek <mkubecek@...e.cz>
To:	Veaceslav Falico <vfalico@...il.com>
Cc:	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, Jay Vosburgh <j.vosburgh@...il.com>,
	Andy Gospodarek <andy@...yhouse.net>,
	Jiri Pirko <jiri@...nulli.us>
Subject: Re: [PATCH net-next 0/3] dev_disable_lro() improvements for stacked
 devices

On Tue, Nov 11, 2014 at 10:05:22AM +0100, Veaceslav Falico wrote:
> On Tue, Nov 11, 2014 at 09:21:30AM +0100, Michal Kubecek wrote:
> >Large receive offloading is known to cause problems if received packets
> >are passed to other host. Therefore the kernel disables it by calling
> >dev_disable_lro() whenever a network device is enslaved in a bridge or
> >forwarding is enabled for it (or globally). For virtual devices we need
> >to disable LRO on the underlying physical device (which is actually
> >receiving the packets).
> >
> >Current dev_disable_lro() code handles this propagation for a vlan
> >(including 802.1ad nested vlan), macvlan or a vlan on top of a macvlan.
> >This patch adds LRO disabling propagation for
> >
> > - macvlan on top of a vlan or any stacked combination of those
> > - bonding
> > - teaming
> 
> All of these drivers use the netdev_upper and friends, so why not make it
> generic with netdev_for_each_all_lower() in dev_disable_lro()?

I wanted to preserve current approach where for vlan and macvlan, LRO is
disabled on the real device instead of the original one (rather than in
addition to it) as LRO is always disabled on them.

Handling all four uniformly would make the code nicer but would bring
unnecessary overhead of traversing the list and dev_disable_lro()
recursion. On the other hand, this operation is not time critical so it
might be acceptable after all.

                                                         Michal Kubecek

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists