From: zhuyj <zyjzyj2000@gmail.com>
To: Willy Tarreau <w@1wt.eu>
Cc: Ben Hutchings <ben@decadent.org.uk>,
"David S. Miller" <davem@davemloft.net>,
netdev@vger.kernel.org, joe@perches.com, julia.lawall@lip6.fr,
dingtianhong@huawei.com, linux-kernel@vger.kernel.org,
jasowang@redhat.com, mst@redhat.com, "Yang,
Zhangle (Eric)" <Zhangle.Yang@windriver.com>,
"Wu, Kuaikuai" <Kuaikuai.Wu@windriver.com>,
"Tao, Yue" <Yue.Tao@windriver.com>
Subject: Re: in kernel 2.6.x, tun/tap nic supports vlan packets
Date: Fri, 25 Apr 2014 16:09:36 +0800 [thread overview]
Message-ID: <535A1840.2010109@gmail.com> (raw)
In-Reply-To: <20140424052447.GC17409@1wt.eu>
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
>
>
next prev parent reply other threads:[~2014-04-25 8:09 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-17 3:35 in kernel 2.6.x, tun/tap nic supports vlan packets zhuyj
2014-04-17 5:02 ` Willy Tarreau
2014-04-17 5:50 ` zhuyj
2014-04-19 13:43 ` zhuyj
2014-04-22 17:53 ` Ben Hutchings
2014-04-23 7:48 ` zhuyj
2014-04-23 11:41 ` Ben Hutchings
2014-04-24 2:10 ` zhuyj
2014-04-24 5:24 ` Willy Tarreau
2014-04-25 8:09 ` zhuyj [this message]
2014-04-17 6:27 ` zhuyj
2014-04-17 13:52 ` zhuyj
2014-04-17 14:23 ` Willy Tarreau
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=535A1840.2010109@gmail.com \
--to=zyjzyj2000@gmail.com \
--cc=Kuaikuai.Wu@windriver.com \
--cc=Yue.Tao@windriver.com \
--cc=Zhangle.Yang@windriver.com \
--cc=ben@decadent.org.uk \
--cc=davem@davemloft.net \
--cc=dingtianhong@huawei.com \
--cc=jasowang@redhat.com \
--cc=joe@perches.com \
--cc=julia.lawall@lip6.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=w@1wt.eu \
/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.