[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <535A1840.2010109@gmail.com>
Date: Fri, 25 Apr 2014 16:09:36 +0800
From: zhuyj <zyjzyj2000@...il.com>
To: Willy Tarreau <w@....eu>
CC: Ben Hutchings <ben@...adent.org.uk>,
"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
joe@...ches.com, julia.lawall@...6.fr, dingtianhong@...wei.com,
linux-kernel@...r.kernel.org, jasowang@...hat.com, mst@...hat.com,
"Yang, Zhangle (Eric)" <Zhangle.Yang@...driver.com>,
"Wu, Kuaikuai" <Kuaikuai.Wu@...driver.com>,
"Tao, Yue" <Yue.Tao@...driver.com>
Subject: Re: in kernel 2.6.x, tun/tap nic supports vlan packets
On 04/24/2014 01:24 PM, Willy Tarreau wrote:
> On Thu, Apr 24, 2014 at 10:10:08AM +0800, zhuyj wrote:
>> On 04/23/2014 07:41 PM, Ben Hutchings wrote:
>>> On Wed, 2014-04-23 at 15:48 +0800, zhuyj wrote:
>>>> On 04/23/2014 01:53 AM, Ben Hutchings wrote:
>>> [...]
>>>>> For what it's worth, I would recommend against applying this. I don't
>>>>> think even Red Hat has backported the VLAN changes, and they have been
>>>>> quite aggressive about backporting features to RHEL 6.
>>>> If we do not merge these patches, maybe RHEL 6 can not make tap driver
>>>> support vlan well.
>>> RHEL 6 isn't based on 2.6.32.y, they do all their own backporting.
>> Hi, Ben
>>
>> It is well known that extraction vlan tag is not implemented in kernel
>> 2.6.32.y. Kernel 2.6.32.y depends on nic hardware to extract vlan tag.
>> So if the patches are not applied, tap driver can not support vlan well.
> What Ben is saying is that RHEL doesn't use 2.6.32.y, but did their own
> fork of 2.6.32 so even if we merged your patch, they wouldn't pick it
> from this tree anyway. However they could possibly take your patch if
> some customers requested the feature even if it's not in 2.6.32.y.
OK. as your wish.
Best Regards!
Zhu Yanjun
>
> Clearly, the fact that nobody complained about this in 4.5 years of
> 2.6.32 means that there's no particular reason any user would suddenly
> miss it now. 2.6.32.y is mostly used to update existing deployments but
> rarely for new deployments. That's why the usefulness of your backport
> in this kernel for its users is likely limited, and at the same time
> the risk of causing a regression is far from being null for existing
> users (eg: if some worked around the issue a different way, their
> workaround would likely not work anymore).
>
> Best regards,
> Willy
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists