Herbert Xu wrote:
BTW, how does the VLAN TX acceleration work at all? It's using
skb->cb to carry the tags but then calls dev_queue_xmit. Once
you do that packet schedulers can scribble all over skb->cb.
Also vlan_skb_recv should be moved out-of-line. It's absolutely
humongous. It'll
On Fri, Nov 16, 2007 at 08:49:02PM +0900, Joonwoo Park wrote:
>
> Not anymore about just e1000 :)
> I made an another patch with different approach which doesn't fix nic driver.
> In addition, this patch does disable all hw vlan acceleration features (rx,
> tx, filter) for promiscuous netdevice.
2007/11/11, Joonwoo Park <[EMAIL PROTECTED]>:
> IMHO even though netdevice is in the promiscuous mode, we should receive all
> of ingress packets.
> This disable the vlan filtering feature when a vlan hw accel configured e1000
> device goes into promiscuous mode.
> This make packets visible to
2007/11/11, Joonwoo Park [EMAIL PROTECTED]:
IMHO even though netdevice is in the promiscuous mode, we should receive all
of ingress packets.
This disable the vlan filtering feature when a vlan hw accel configured e1000
device goes into promiscuous mode.
This make packets visible to sniffers
Herbert Xu wrote:
BTW, how does the VLAN TX acceleration work at all? It's using
skb-cb to carry the tags but then calls dev_queue_xmit. Once
you do that packet schedulers can scribble all over skb-cb.
Also vlan_skb_recv should be moved out-of-line. It's absolutely
humongous. It'll generate
On Fri, Nov 16, 2007 at 08:49:02PM +0900, Joonwoo Park wrote:
Not anymore about just e1000 :)
I made an another patch with different approach which doesn't fix nic driver.
In addition, this patch does disable all hw vlan acceleration features (rx,
tx, filter) for promiscuous netdevice. (It
Patrick McHardy wrote:
> Kok, Auke wrote:
>> Patrick McHardy wrote:
>>> Kok, Auke wrote:
Patrick McHardy wrote:
> I already posted a patch for this, not sure what happened to it.
> Auke, any news on merging the secondary unicast address support?
I dropped the ball on that
> "AK" == Kok, Auke <[EMAIL PROTECTED]> writes:
AK> actually the impact can be quite negative, imagine doing a tcpdump
AK> on a 10gig interface with vlan's enabled - all of a sudden you
AK> might accidentally flood the system with a 100-fold increase in
AK> traffic and force the stack to dump
Kok, Auke wrote:
Patrick McHardy wrote:
Kok, Auke wrote:
Patrick McHardy wrote:
I already posted a patch for this, not sure what happened to it.
Auke, any news on merging the secondary unicast address support?
I dropped the ball on that one. Care to resend it and send me one for
e1000e as
Kok, Auke wrote:
Patrick McHardy wrote:
Kok, Auke wrote:
Patrick McHardy wrote:
I already posted a patch for this, not sure what happened to it.
Auke, any news on merging the secondary unicast address support?
I dropped the ball on that one. Care to resend it and send me one for
e1000e as
AK == Kok, Auke [EMAIL PROTECTED] writes:
AK actually the impact can be quite negative, imagine doing a tcpdump
AK on a 10gig interface with vlan's enabled - all of a sudden you
AK might accidentally flood the system with a 100-fold increase in
AK traffic and force the stack to dump all those
Patrick McHardy wrote:
Kok, Auke wrote:
Patrick McHardy wrote:
Kok, Auke wrote:
Patrick McHardy wrote:
I already posted a patch for this, not sure what happened to it.
Auke, any news on merging the secondary unicast address support?
I dropped the ball on that one. Care to resend it and
> > I'll work e1000e too :-)
>
> awesome, looking forward to that.
>
BTW, It seems to need Patrick's unicast patch for e1000e first.
I'll looking forward to that too.
Thanks
Joonwoo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Joonwoo Park wrote:
> 2007/11/14, Kok, Auke <[EMAIL PROTECTED]>:
>> Patrick McHardy wrote:
>>> Kok, Auke wrote:
Patrick McHardy wrote:
> I already posted a patch for this, not sure what happened to it.
> Auke, any news on merging the secondary unicast address support?
I
2007/11/14, Kok, Auke <[EMAIL PROTECTED]>:
> Patrick McHardy wrote:
> > Kok, Auke wrote:
> >> Patrick McHardy wrote:
> >>
> >>> I already posted a patch for this, not sure what happened to it.
> >>> Auke, any news on merging the secondary unicast address support?
> >>
> >> I dropped the ball on
On Sun, 11 Nov 2007 09:51:20 +0900
"Joonwoo Park" <[EMAIL PROTECTED]> wrote:
> IMHO even though netdevice is in the promiscuous mode, we should receive all
> of ingress packets.
> This disable the vlan filtering feature when a vlan hw accel configured e1000
> device goes into promiscuous mode.
Patrick McHardy wrote:
> Kok, Auke wrote:
>> Patrick McHardy wrote:
>>
>>> I already posted a patch for this, not sure what happened to it.
>>> Auke, any news on merging the secondary unicast address support?
>>
>> I dropped the ball on that one. Care to resend it and send me one for
>> e1000e as
Patrick McHardy wrote:
> Kok, Auke wrote:
>> Patrick McHardy wrote:
>>
>>> I already posted a patch for this, not sure what happened to it.
>>> Auke, any news on merging the secondary unicast address support?
>>
>> I dropped the ball on that one. Care to resend it and send me one for
>> e1000e as
Kok, Auke wrote:
Patrick McHardy wrote:
I already posted a patch for this, not sure what happened to it.
Auke, any news on merging the secondary unicast address support?
I dropped the ball on that one. Care to resend it and send me one for e1000e as
well?
Patch for e1000 attached.
Does
Patrick McHardy wrote:
> Herbert Xu wrote:
>> On Tue, Nov 13, 2007 at 04:06:24AM -0800, David Miller wrote:
In other words we can make it so that nobody is in promiscuous
mode and therefore have to disable VLAN acceleration *unless*
they really want to be in that state. In which
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Tue, 13 Nov 2007 20:16:47 +0800
> Perhaps those who want to push this patch should be encouraged
> to convert e1000 to the new interface :)
That is my feeling as well :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Herbert Xu wrote:
On Tue, Nov 13, 2007 at 04:06:24AM -0800, David Miller wrote:
In other words we can make it so that nobody is in promiscuous
mode and therefore have to disable VLAN acceleration *unless*
they really want to be in that state. In which case it would
imply that they wish to see
On Tue, Nov 13, 2007 at 04:06:24AM -0800, David Miller wrote:
>
> > In other words we can make it so that nobody is in promiscuous
> > mode and therefore have to disable VLAN acceleration *unless*
> > they really want to be in that state. In which case it would
> > imply that they wish to see
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Tue, 13 Nov 2007 20:03:28 +0800
> On Tue, Nov 13, 2007 at 03:36:11AM -0800, David Miller wrote:
> >
> > The performance implications can be pretty severe however.
> > I wish we could address this somehow.
>
> Or perhaps we should just teach everyone to
On Tue, Nov 13, 2007 at 03:36:11AM -0800, David Miller wrote:
>
> The performance implications can be pretty severe however.
> I wish we could address this somehow.
Or perhaps we should just teach everyone to always run tcpdump
with -p, like me :)
Of course this would still have a negative
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Tue, 13 Nov 2007 19:09:23 +0800
> I agree. People doing a tcpdump don't have to turn on promiscuous
> mode, that's what the -p option is for. In other words, having
> promiscuous mode disable VLAN filtering does not take away the
> user's options at
Patrick McHardy <[EMAIL PROTECTED]> wrote:
>
> I still think promiscous mode should disable all filters (which would
> also provide a consistent view between accerlated and non-accerlated
> devices), but an ethtool option is better than nothing :)
I agree. People doing a tcpdump don't have to
Joonwoo Park wrote:
2007/11/13, David Miller <[EMAIL PROTECTED]>:
From: Willy Tarreau <[EMAIL PROTECTED]>
Date: Tue, 13 Nov 2007 00:32:57 +0100
At least, being able to disable the feature at module load time
would be acceptable. Many people who often need to sniff on decent
machines
Joonwoo Park wrote:
2007/11/13, David Miller [EMAIL PROTECTED]:
From: Willy Tarreau [EMAIL PROTECTED]
Date: Tue, 13 Nov 2007 00:32:57 +0100
At least, being able to disable the feature at module load time
would be acceptable. Many people who often need to sniff on decent
machines would
Patrick McHardy [EMAIL PROTECTED] wrote:
I still think promiscous mode should disable all filters (which would
also provide a consistent view between accerlated and non-accerlated
devices), but an ethtool option is better than nothing :)
I agree. People doing a tcpdump don't have to turn on
From: Herbert Xu [EMAIL PROTECTED]
Date: Tue, 13 Nov 2007 19:09:23 +0800
I agree. People doing a tcpdump don't have to turn on promiscuous
mode, that's what the -p option is for. In other words, having
promiscuous mode disable VLAN filtering does not take away the
user's options at all.
On Tue, Nov 13, 2007 at 03:36:11AM -0800, David Miller wrote:
The performance implications can be pretty severe however.
I wish we could address this somehow.
Or perhaps we should just teach everyone to always run tcpdump
with -p, like me :)
Of course this would still have a negative impact
From: Herbert Xu [EMAIL PROTECTED]
Date: Tue, 13 Nov 2007 20:03:28 +0800
On Tue, Nov 13, 2007 at 03:36:11AM -0800, David Miller wrote:
The performance implications can be pretty severe however.
I wish we could address this somehow.
Or perhaps we should just teach everyone to always run
On Tue, Nov 13, 2007 at 04:06:24AM -0800, David Miller wrote:
In other words we can make it so that nobody is in promiscuous
mode and therefore have to disable VLAN acceleration *unless*
they really want to be in that state. In which case it would
imply that they wish to see everything
Herbert Xu wrote:
On Tue, Nov 13, 2007 at 04:06:24AM -0800, David Miller wrote:
In other words we can make it so that nobody is in promiscuous
mode and therefore have to disable VLAN acceleration *unless*
they really want to be in that state. In which case it would
imply that they wish to see
From: Herbert Xu [EMAIL PROTECTED]
Date: Tue, 13 Nov 2007 20:16:47 +0800
Perhaps those who want to push this patch should be encouraged
to convert e1000 to the new interface :)
That is my feeling as well :-)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of
Patrick McHardy wrote:
Herbert Xu wrote:
On Tue, Nov 13, 2007 at 04:06:24AM -0800, David Miller wrote:
In other words we can make it so that nobody is in promiscuous
mode and therefore have to disable VLAN acceleration *unless*
they really want to be in that state. In which case it would
Kok, Auke wrote:
Patrick McHardy wrote:
I already posted a patch for this, not sure what happened to it.
Auke, any news on merging the secondary unicast address support?
I dropped the ball on that one. Care to resend it and send me one for e1000e as
well?
Patch for e1000 attached.
Does
Patrick McHardy wrote:
Kok, Auke wrote:
Patrick McHardy wrote:
I already posted a patch for this, not sure what happened to it.
Auke, any news on merging the secondary unicast address support?
I dropped the ball on that one. Care to resend it and send me one for
e1000e as well?
Patch
Patrick McHardy wrote:
Kok, Auke wrote:
Patrick McHardy wrote:
I already posted a patch for this, not sure what happened to it.
Auke, any news on merging the secondary unicast address support?
I dropped the ball on that one. Care to resend it and send me one for
e1000e as well?
Patch
On Sun, 11 Nov 2007 09:51:20 +0900
Joonwoo Park [EMAIL PROTECTED] wrote:
IMHO even though netdevice is in the promiscuous mode, we should receive all
of ingress packets.
This disable the vlan filtering feature when a vlan hw accel configured e1000
device goes into promiscuous mode.
This
2007/11/14, Kok, Auke [EMAIL PROTECTED]:
Patrick McHardy wrote:
Kok, Auke wrote:
Patrick McHardy wrote:
I already posted a patch for this, not sure what happened to it.
Auke, any news on merging the secondary unicast address support?
I dropped the ball on that one. Care to resend it
Joonwoo Park wrote:
2007/11/14, Kok, Auke [EMAIL PROTECTED]:
Patrick McHardy wrote:
Kok, Auke wrote:
Patrick McHardy wrote:
I already posted a patch for this, not sure what happened to it.
Auke, any news on merging the secondary unicast address support?
I dropped the ball on that one. Care
I'll work e1000e too :-)
awesome, looking forward to that.
BTW, It seems to need Patrick's unicast patch for e1000e first.
I'll looking forward to that too.
Thanks
Joonwoo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
2007/11/13, David Miller <[EMAIL PROTECTED]>:
> From: Willy Tarreau <[EMAIL PROTECTED]>
> Date: Tue, 13 Nov 2007 00:32:57 +0100
>
> > At least, being able to disable the feature at module load time
> > would be acceptable. Many people who often need to sniff on decent
> > machines would always
2007/11/13, Willy Tarreau <[EMAIL PROTECTED]>:
> On Mon, Nov 12, 2007 at 02:57:16PM -0800, David Miller wrote:
> > From: "Chris Friesen" <[EMAIL PROTECTED]>
> > Date: Mon, 12 Nov 2007 16:43:24 -0600
> >
> > > David Miller wrote:
> > >
> > > > When you select VLAN, you by definition are asking for
From: Willy Tarreau <[EMAIL PROTECTED]>
Date: Tue, 13 Nov 2007 00:32:57 +0100
> At least, being able to disable the feature at module load time
> would be acceptable. Many people who often need to sniff on decent
> machines would always keep it disabled.
I'm willing to accept the feature, in
Willy Tarreau wrote:
> On Mon, Nov 12, 2007 at 03:19:23PM -0800, David Miller wrote:
>> From: Willy Tarreau <[EMAIL PROTECTED]>
>> Date: Tue, 13 Nov 2007 00:15:16 +0100
>>
>>> I can say that sometimes you'd like to be aware that one of your
>>> VLANs is wrong and you'd simply like to sniff the
On Mon, Nov 12, 2007 at 03:19:23PM -0800, David Miller wrote:
> From: Willy Tarreau <[EMAIL PROTECTED]>
> Date: Tue, 13 Nov 2007 00:15:16 +0100
>
> > I can say that sometimes you'd like to be aware that one of your
> > VLANs is wrong and you'd simply like to sniff the wire to guess the
> >
From: Willy Tarreau <[EMAIL PROTECTED]>
Date: Tue, 13 Nov 2007 00:15:16 +0100
> I can say that sometimes you'd like to be aware that one of your
> VLANs is wrong and you'd simply like to sniff the wire to guess the
> correct tag. And on production, you simply cannot remove other
> VLANs,
On Mon, Nov 12, 2007 at 02:57:16PM -0800, David Miller wrote:
> From: "Chris Friesen" <[EMAIL PROTECTED]>
> Date: Mon, 12 Nov 2007 16:43:24 -0600
>
> > David Miller wrote:
> >
> > > When you select VLAN, you by definition are asking for non-VLAN
> > > traffic to be elided. It is like plugging
From: "Chris Friesen" <[EMAIL PROTECTED]>
Date: Mon, 12 Nov 2007 16:43:24 -0600
> David Miller wrote:
>
> > When you select VLAN, you by definition are asking for non-VLAN
> > traffic to be elided. It is like plugging the ethernet cable
> > into one switch or another.
>
> For max functionality
Chris Friesen wrote:
> David Miller wrote:
>
>> When you select VLAN, you by definition are asking for non-VLAN
>> traffic to be elided. It is like plugging the ethernet cable
>> into one switch or another.
>
> For max functionality it seems like the raw eth device should show
> everything on
David Miller wrote:
When you select VLAN, you by definition are asking for non-VLAN
traffic to be elided. It is like plugging the ethernet cable
into one switch or another.
For max functionality it seems like the raw eth device should show
everything on the wire in promiscuous mode.
If we
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Mon, 12 Nov 2007 18:21:35 +0100
> Do you really consider that a realistic choice? Who is going to
> remove interfaces that are in use just to see traffic for other
> VLANs? Sniffing specific VLANs can always be done on the VLAN
> device itself.
From: "Kok, Auke" <[EMAIL PROTECTED]>
Date: Mon, 12 Nov 2007 09:12:40 -0800
> Actually I think this patch removes a choice from the user.
>
> Before this patch, the user can sniff all traffic by disabling vlans, or a
> specific vlan only by leaving vlans on when going into promisc mode.
>
>
Patrick McHardy wrote:
> Kok, Auke wrote:
>> Joonwoo Park wrote:
>>> IMHO even though netdevice is in the promiscuous mode, we should receive
>>> all of ingress packets.
>>> This disable the vlan filtering feature when a vlan hw accel configured
>>> e1000 device goes into promiscuous mode.
>>>
Kok, Auke wrote:
Joonwoo Park wrote:
IMHO even though netdevice is in the promiscuous mode, we should receive all of
ingress packets.
This disable the vlan filtering feature when a vlan hw accel configured e1000
device goes into promiscuous mode.
This make packets visible to sniffers though
Joonwoo Park wrote:
> IMHO even though netdevice is in the promiscuous mode, we should receive all
> of ingress packets.
> This disable the vlan filtering feature when a vlan hw accel configured e1000
> device goes into promiscuous mode.
> This make packets visible to sniffers though it's not
Joonwoo Park wrote:
IMHO even though netdevice is in the promiscuous mode, we should receive all
of ingress packets.
This disable the vlan filtering feature when a vlan hw accel configured e1000
device goes into promiscuous mode.
This make packets visible to sniffers though it's not vlan id
Kok, Auke wrote:
Joonwoo Park wrote:
IMHO even though netdevice is in the promiscuous mode, we should receive all of
ingress packets.
This disable the vlan filtering feature when a vlan hw accel configured e1000
device goes into promiscuous mode.
This make packets visible to sniffers though
Patrick McHardy wrote:
Kok, Auke wrote:
Joonwoo Park wrote:
IMHO even though netdevice is in the promiscuous mode, we should receive
all of ingress packets.
This disable the vlan filtering feature when a vlan hw accel configured
e1000 device goes into promiscuous mode.
This make packets
From: Kok, Auke [EMAIL PROTECTED]
Date: Mon, 12 Nov 2007 09:12:40 -0800
Actually I think this patch removes a choice from the user.
Before this patch, the user can sniff all traffic by disabling vlans, or a
specific vlan only by leaving vlans on when going into promisc mode.
After this
From: Patrick McHardy [EMAIL PROTECTED]
Date: Mon, 12 Nov 2007 18:21:35 +0100
Do you really consider that a realistic choice? Who is going to
remove interfaces that are in use just to see traffic for other
VLANs? Sniffing specific VLANs can always be done on the VLAN
device itself.
Change
David Miller wrote:
When you select VLAN, you by definition are asking for non-VLAN
traffic to be elided. It is like plugging the ethernet cable
into one switch or another.
For max functionality it seems like the raw eth device should show
everything on the wire in promiscuous mode.
If we
Chris Friesen wrote:
David Miller wrote:
When you select VLAN, you by definition are asking for non-VLAN
traffic to be elided. It is like plugging the ethernet cable
into one switch or another.
For max functionality it seems like the raw eth device should show
everything on the wire in
From: Chris Friesen [EMAIL PROTECTED]
Date: Mon, 12 Nov 2007 16:43:24 -0600
David Miller wrote:
When you select VLAN, you by definition are asking for non-VLAN
traffic to be elided. It is like plugging the ethernet cable
into one switch or another.
For max functionality it seems like
On Mon, Nov 12, 2007 at 02:57:16PM -0800, David Miller wrote:
From: Chris Friesen [EMAIL PROTECTED]
Date: Mon, 12 Nov 2007 16:43:24 -0600
David Miller wrote:
When you select VLAN, you by definition are asking for non-VLAN
traffic to be elided. It is like plugging the ethernet cable
From: Willy Tarreau [EMAIL PROTECTED]
Date: Tue, 13 Nov 2007 00:15:16 +0100
I can say that sometimes you'd like to be aware that one of your
VLANs is wrong and you'd simply like to sniff the wire to guess the
correct tag. And on production, you simply cannot remove other
VLANs, otherwise you
Willy Tarreau wrote:
On Mon, Nov 12, 2007 at 03:19:23PM -0800, David Miller wrote:
From: Willy Tarreau [EMAIL PROTECTED]
Date: Tue, 13 Nov 2007 00:15:16 +0100
I can say that sometimes you'd like to be aware that one of your
VLANs is wrong and you'd simply like to sniff the wire to guess the
On Mon, Nov 12, 2007 at 03:19:23PM -0800, David Miller wrote:
From: Willy Tarreau [EMAIL PROTECTED]
Date: Tue, 13 Nov 2007 00:15:16 +0100
I can say that sometimes you'd like to be aware that one of your
VLANs is wrong and you'd simply like to sniff the wire to guess the
correct tag. And
From: Willy Tarreau [EMAIL PROTECTED]
Date: Tue, 13 Nov 2007 00:32:57 +0100
At least, being able to disable the feature at module load time
would be acceptable. Many people who often need to sniff on decent
machines would always keep it disabled.
I'm willing to accept the feature, in whatever
2007/11/13, Willy Tarreau [EMAIL PROTECTED]:
On Mon, Nov 12, 2007 at 02:57:16PM -0800, David Miller wrote:
From: Chris Friesen [EMAIL PROTECTED]
Date: Mon, 12 Nov 2007 16:43:24 -0600
David Miller wrote:
When you select VLAN, you by definition are asking for non-VLAN
traffic to
2007/11/13, David Miller [EMAIL PROTECTED]:
From: Willy Tarreau [EMAIL PROTECTED]
Date: Tue, 13 Nov 2007 00:32:57 +0100
At least, being able to disable the feature at module load time
would be acceptable. Many people who often need to sniff on decent
machines would always keep it
IMHO even though netdevice is in the promiscuous mode, we should receive all of
ingress packets.
This disable the vlan filtering feature when a vlan hw accel configured e1000
device goes into promiscuous mode.
This make packets visible to sniffers though it's not vlan id of itself.
Any check,
IMHO even though netdevice is in the promiscuous mode, we should receive all of
ingress packets.
This disable the vlan filtering feature when a vlan hw accel configured e1000
device goes into promiscuous mode.
This make packets visible to sniffers though it's not vlan id of itself.
Any check,
76 matches
Mail list logo
