On 04/17/2014 01:02 PM, Willy Tarreau wrote:
Hi Zhu,
On Thu, Apr 17, 2014 at 11:35:58AM +0800, zhuyj wrote:
Hi, all
In kernel 2.6.x, linux depends on nic vlan hardware acceleration to
insert/extract
vlan tag. In this scene, in kernel 2.6.x
_____ ________
A | | B | | C
vlan packets-->| tap |----->|vlan nic|--->
|_____| |________|
We hope vlan packets pass through tap and vlan nic from A to c.
But in kernel 2.6.x, linux kernel can not extract vlan tag. It depends
on nic vlan hardware acceleration. It is well known that tap nic has no
vlan acceleration. So in the above scene, vlan packets can not be handled by
tap nic. These vlan packets will be discarded in B. They can not arrive
at C.
It's not clear to me what you want to achieve. Are you trying to create
vlan interfaces on top of a tap interface ? Eg: tap1.12, tap1.23 etc ?
Hi, Willy
Yes. These 2 patches are trying create vlan interfaces on top of a tap
interface.
Zhu Yanjun
In kernel 3.x, linux can handle vlan packets. It does not depend on nic vlan
hardware acceleration. So the above scene can work well in kernel 3.x.
To resolve the above in kernel 2.6.x, we simulated vlan hardware
acceleration in
tun/tap driver. Then followed the logic of commit commit 4fba4ca4
[vlan: Centralize handling of hardware acceleration] to modify the vlan
packets
process in kernel 2.6.x. In the end, the above scene can work well in
patched
kernel 2.6.x.
Please comment on it. Any reply is appreciated.
Hi, Willy
These 2 patches are for linux2.6.x. These can work well here. Please
help to merge
linux 2.6.32.x. Thanks a lot.
Well, 2.6.32.x is in deep freeze mode and it receives only critical fixes
once in a while. While I can appreciate that the patch above might solve
the issue you're facing, I'm wondering if there are not any acceptable
workarounds for such a deep freeze kernel. You patch is not huge, but it
definitely affects a working driver, and I wouldn't like risking to break
the tap driver for other users, and I reall don't have the skills to audit
it completely to ensure this is not the case. And if it breaks, I'll have
to revert it or seek for some help on netdev.
So I'd say that I'd rather not merge it unless I get an Acked-by from some
netdev people who are willing to help in case of any future regression,
which is unlikely but still possible.
Just out of curiosity, what is the motivation for ongoing development on
top of 2.6.32 ? Are there any important deployments that cannot upgrade
for any specific reason ? I'm asking because most 2.6.32.x kernels that
are stuffed into embedded boxes very likely come with their own number
of in-house patches to add whatever feature is needed in such contexts,
so I'm wondering why having this patch in mainline would help in your
situation compared to having it into your own patch set only.
Thanks,
Willy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
