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  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, 29 Apr 2008 17:42:48 -0700
From:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
To:	"Patrick McHardy" <kaber@...sh.net>,
	"Kok, Auke-jan H" <auke-jan.h.kok@...el.com>
Cc:	<jeff@...zik.org>, <netdev@...r.kernel.org>,
	<e1000-devel@...ts.sourceforge.net>
Subject: RE: [PATCH 3/5] e1000e: Allow TSO to trickle down to VLAN device

> That was a typo, I meant netdev_features_change(), which is invoked
> by dev_ethtool() and calls the netdev notifier with 
> NETDEV_FEAT_CHANGE,
> on which the VLAN code could react. I wasn't aware of the TSO + VLAN
> acceleration problems you've mentioned, do you have a pointer to more
> information about this?
> 
> In any case I would prefer to avoid having drivers mess with VLAN
> device flags. How about adding a device flag indicating that the
> driver supports TSO + VLAN acceleration and using the
> NETDEV_FEAT_CHANGE notification inside the VLAN code do adjust
> the device's flags properly?

I've been looking into this, and I agree this makes sense when creating
a new VLAN to get the device flags to the VLAN device.  However, we need
to get the TSO and/or Tx checksum offload feature flags off all VLAN
devices when the parent device has it turned off.  I don't see any clean
way of doing this with netdev_features_change().  I'd really love to
implement this correctly, so if you have any ideas on how to handle this
latter case, I'm all ears.  :-)

Thanks Patrick,
-PJ Waskiewicz
--
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