From: Ichiro Suzuki <isuzuki@miraclelinux.com>
To: Patrick McHardy <kaber@trash.net>
Cc: "Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@intel.com>,
netdev@vger.kernel.org, Naohiro Ooiwa <nooiwa@miraclelinux.com>
Subject: Re: Question about VLAN + checksum offloading
Date: Tue, 20 May 2008 12:19:48 +0900 [thread overview]
Message-ID: <1211253588.9823.2.camel@localhost.localdomain> (raw)
In-Reply-To: <4831BC4D.7000601@trash.net>
Thank you, PJ and Patrick.
I'll revisit the code after VLAN patches are posted.
----------------------------------------------
Ichiro Suzuki <isuzuki@miraclelinux.com>
Miracle Linux Corp., Advanced Technology Group
----------------------------------------------
On Mon, 2008-05-19 at 19:43 +0200, Patrick McHardy wrote:
> Waskiewicz Jr, Peter P wrote:
> >> o If so, is there any mechanism to propagate
> >> real_dev->features flags in vlan.c?
> >
> > There isn't an explicit way. I had written patches into e1000, igb,
> > e1000e, and ixgbe to propogate the VLAN flags within the driver when the
> > VLAN device was created. The trick though is if you remove a feature
> > flag with ethtool, say checksum offload, on your main device, you
> > probably should turn it off on your VLAN devices. Patrick McHardy
> > pointed me at netdev_feature_change() to use within the driver. I'll
> > admit I haven't had the time to fix my drivers to use this call, but it
> > certainly looks like the way to go. Please see the (middle) of the
> > thread here: http://marc.info/?l=linux-netdev&m=120878809806631&w=2
> >
> >> o If such mechanism doesn't exist, is my patch reasonable?
> >
> > I would say yes, halfway. The issue is you probably want to remove the
> > feature flag from the VLAN device if you removed the flag from the
> > parent device as well.
>
>
> Yes, it should use the same mechanism as suggested for the
> VLAN accel feature. And it should be limited to features
> that are known to work, not just blindly copy everything.
>
> I will be catching up with the VLAN patches posted recently
> sometime next week. I guess I can then also add a patch for
> feature propagation myself if you don't beat me to it :)
>
>
prev parent reply other threads:[~2008-05-20 3:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-16 7:52 Question about VLAN + checksum offloading Ichiro Suzuki
2008-05-19 17:36 ` Waskiewicz Jr, Peter P
2008-05-19 17:43 ` Patrick McHardy
2008-05-19 17:45 ` Patrick McHardy
2008-05-20 3:19 ` Ichiro Suzuki [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1211253588.9823.2.camel@localhost.localdomain \
--to=isuzuki@miraclelinux.com \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.org \
--cc=nooiwa@miraclelinux.com \
--cc=peter.p.waskiewicz.jr@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.