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.
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.
Best Regards!
Zhu Yanjun
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
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
>
>
Hi, Jaso
Would you like to code review these 2 patches?
Thanks a lot.
Zhu Yanjun
On 04/17/2014 11:35 AM, 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.
>
> 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.
>
> Best Regards!
> Zhu Yanjun
>
Although the maintainer will not merge these 2 patches, I still fix the
mistakes in these 2 patches. Now the latest patches are in attachment.
Maybe these patches can help others.
The latest patches fix mistakes in rx stats.
Best Regards!
Zhu Yanjun
On 04/17/2014 11:35 AM, 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.
>
> 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.
>
> Best Regards!
> Zhu Yanjun
>
On Thu, Apr 17, 2014 at 09:52:41PM +0800, zhuyj wrote:
> Although the maintainer will not merge these 2 patches, I still fix the
> mistakes in these 2 patches. Now the latest patches are in attachment.
Just for the record, I didn't say I "will not" merge them but that I will
not "without an Acked-by from some netdev people who are willing to help
in case of any future regression, which is unlikely but still possible".
That means that if you find someone here to vouch for your patches, I'll
gladly merge them into 2.6.32.x, otherwise not.
> Maybe these patches can help others.
>
> The latest patches fix mistakes in rx stats.
>
> Best Regards!
> Zhu Yanjun
Thanks,
Willy
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 ?
>
>> 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.
Hi, Willy
I want to submit these 2 patches to this long-term kernel. I have 2
purposes:
1. I want to share these 2 patches with the ones who need this kind of
feature. Maybe these 2 patches can help them.
2. When many people make use of these 2 patches, we will find some
defects. Then we fix them and make this kind of feature better.
Zhu Yanjun
> Thanks,
> Willy
>
>
On Thu, 2014-04-17 at 07:02 +0200, 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.
This is a gross overstatement.
The problem I know of is that prior to Linux 2.6.37 the RX path behaved
differently for VLAN-tagged packets depending on whether they were
extracted by the driver/hardware.
If you put a bridge (or bond) and VLAN device on top of a single
physical device that doesn't do VLAN tag extraction, the VLAN device
didn't get any packets because the bridge packet handler was called
first. Whereas, if the driver called the 'VLAN accelerated' RX path,
the VLAN packet handler was called first. (Linux 2.6.37 actually
standardised on the former behaviour, and 3.2 fixed it to be the
latter.)
I don't know whether that's the problem zhuyj has run into.
[...]
> 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,
I think it's huge by the standards of 2.6.32.y.
> 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.
[...]
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.
Ben.
--
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein
On 04/23/2014 01:53 AM, Ben Hutchings wrote:
> On Thu, 2014-04-17 at 07:02 +0200, 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.
Hi, Ben
Thanks for your reply.
> This is a gross overstatement.
>
> The problem I know of is that prior to Linux 2.6.37 the RX path behaved
> differently for VLAN-tagged packets depending on whether they were
> extracted by the driver/hardware.
Yes. You are right. So I backported
0002-vlan-Centralize-handling-of-hardware-acceleration.patch to fix this
problem.
>
> If you put a bridge (or bond) and VLAN device on top of a single
> physical device that doesn't do VLAN tag extraction, the VLAN device
> didn't get any packets because the bridge packet handler was called
> first. Whereas, if the driver called the 'VLAN accelerated' RX path,
> the VLAN packet handler was called first. (Linux 2.6.37 actually
> standardised on the former behaviour, and 3.2 fixed it to be the
> latter.)
Yes. So I made a patch
"0001-tun-tap-add-the-feature-of-vlan-rx-extraction.patch" to make tap
driver extract vlan tag.
>
> I don't know whether that's the problem zhuyj has run into.
>
> [...]
>> 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,
> I think it's huge by the standards of 2.6.32.y.
>
>> 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.
> [...]
>
> 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.
Best Regards!
Zhu Yanjun
>
> Ben.
>
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.
Ben.
--
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein
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.
Best Regards!
Zhu Yanjun
> Ben.
>
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.
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
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
>
>