[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <D5C1322C3E673F459512FB59E0DDC329051F3761@orsmsx414.amr.corp.intel.com>
Date: Thu, 22 May 2008 11:18:59 -0700
From: "Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
To: "Patrick McHardy" <kaber@...sh.net>
Cc: "Herbert Xu" <herbert@...dor.apana.org.au>, <davem@...emloft.net>,
<netdev@...r.kernel.org>
Subject: RE: [RFC, VLAN]: Propagate selected feature bits to VLAN devices
> Waskiewicz Jr, Peter P wrote:
> >>> I thought about this myself, my second idea was to add a mask for
> >>> feature bits to be propagated. Unless there is a need for
> >>>
> >> the driver
> >>
> >>> to determine them at runtime, thats slightly simpler. The
> >>>
> >> driver would
> >>
> >>> do:
> >>>
> >>> dev->vlan_features = NETIF_F_CSUM_ALL | ...
> >>>
> >>> What do you think about this?
> >>>
> >> Yes that sounds great!
> >>
> >
> > The issue is how does the driver know how to pull those
> flags off the
> > VLAN device when the parent has TSO or CSUM offload disabled? The
> > only way I could come up with it was in my original patch in the
> > drivers to loop through the entire VLAN group array, and clear the
> > flag on existing devices.
> >
>
> Yes, thats also what my patch is doing. Not a big deal I
> guess, we're doing that for all kinds of notifications
> already and nobody ever complained.
I guess I misunderstood what you were suggesting to re-implement with
Herbert. I like your current patch as-is, but if something different is
coming, I'll just sit tight for it. I already spun the ixgbe, igb, and
e1000e patches to use the new interface, and they should be coming out
shortly. But if we need to update them later, that's cool.
Cheers,
-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