Re: in kernel 2.6.x, tun/tap nic supports vlan packets

[Willy Tarreau <w@1wt.eu>]

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 ?

> 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