All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kok, Auke" <auke-jan.h.kok@intel.com>
To: Willy Tarreau <w@1wt.eu>
Cc: David Miller <davem@davemloft.net>,
	cfriesen@nortel.com, kaber@trash.net, joonwpark81@gmail.com,
	netdev@vger.kernel.org,
	djohnson+linux-kernel@sw.starentnetworks.com,
	linux-kernel@vger.kernel.org, e1000-devel@lists.sourceforge.net
Subject: Re: [PATCH 2/2] [e1000 VLAN] Disable vlan hw accel when promiscuous mode
Date: Mon, 12 Nov 2007 15:38:44 -0800	[thread overview]
Message-ID: <4738E404.8020105@intel.com> (raw)
In-Reply-To: <20071112233257.GA15524@1wt.eu>

Willy Tarreau wrote:
> On Mon, Nov 12, 2007 at 03:19:23PM -0800, David Miller wrote:
>> From: Willy Tarreau <w@1wt.eu>
>> 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 disrupt the service.
>> If you were plugged into the wrong physical switch, how might
>> you debug that problem in production? :-)
> 
> tcpdump on an unfiltered RJ45 tells you a lot of things. Some switches
> for instance send keepalive packets (ether proto 9000) with their own
> MAC as source+dest, others send CDP packets, etc... I've very rarely
> stayed plugged to the wrong switch for too long before discovering it.
> But that requires the ability to sniff.
> 
>> Really, it's the same issue, just virtualized, as in the name
>> for the feature, VLAN.
> 
> No, it's not the same, because as soon as you pass through a switch
> which is not configured for VLANs, it does not make any distinction,
> and the same DMAC is considered on a single port whatever the VLAN.
> This is not true with multiple switches. Also, sometimes, being able
> to see that your port gets flooded with traffic for a VLAN on which
> you're not configured helps you understand why you cannot fill the
> port.
> 
> I'd like that we can use the hardware correctly without having to
> buy TAPs. It reminds me the discussions about TOE. You claim
> yourself that TOE is bad in part because you have little if any
> control on the bugs on the TCP stack on the chip. This is the same
> here. If I know that the chip does not send me what it receives
> when configured in promiscuous mode, I can I swear it never received
> the missing packet ? There's always a doubt. Maybe sometimes the
> filter is buggy, maybe it only passes tags when the remaining bits
> are all zero, etc... Promiscuous mode generally means that you're
> the closest possible to the wire. We already do not receive pause
> frames and sometimes that's annoying. But having no control over
> what we want to see is frustrating.
> 
> 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 really do not want to add another module parameter to the driver for this. It
seems bogus as well: if we can agree on one sane choice it's much better, and if
we don't then we should use ethtool to provide a uniform way of implementing this
for all drivers sanely.

Auke

WARNING: multiple messages have this Message-ID (diff)
From: "Kok, Auke" <auke-jan.h.kok@intel.com>
To: Willy Tarreau <w@1wt.eu>
Cc: e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
	djohnson+linux-kernel@sw.starentnetworks.com,
	linux-kernel@vger.kernel.org, joonwpark81@gmail.com,
	kaber@trash.net, cfriesen@nortel.com,
	David Miller <davem@davemloft.net>
Subject: Re: [PATCH 2/2] [e1000 VLAN] Disable vlan hw accel when promiscuous mode
Date: Mon, 12 Nov 2007 15:38:44 -0800	[thread overview]
Message-ID: <4738E404.8020105@intel.com> (raw)
In-Reply-To: <20071112233257.GA15524@1wt.eu>

Willy Tarreau wrote:
> On Mon, Nov 12, 2007 at 03:19:23PM -0800, David Miller wrote:
>> From: Willy Tarreau <w@1wt.eu>
>> 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 disrupt the service.
>> If you were plugged into the wrong physical switch, how might
>> you debug that problem in production? :-)
> 
> tcpdump on an unfiltered RJ45 tells you a lot of things. Some switches
> for instance send keepalive packets (ether proto 9000) with their own
> MAC as source+dest, others send CDP packets, etc... I've very rarely
> stayed plugged to the wrong switch for too long before discovering it.
> But that requires the ability to sniff.
> 
>> Really, it's the same issue, just virtualized, as in the name
>> for the feature, VLAN.
> 
> No, it's not the same, because as soon as you pass through a switch
> which is not configured for VLANs, it does not make any distinction,
> and the same DMAC is considered on a single port whatever the VLAN.
> This is not true with multiple switches. Also, sometimes, being able
> to see that your port gets flooded with traffic for a VLAN on which
> you're not configured helps you understand why you cannot fill the
> port.
> 
> I'd like that we can use the hardware correctly without having to
> buy TAPs. It reminds me the discussions about TOE. You claim
> yourself that TOE is bad in part because you have little if any
> control on the bugs on the TCP stack on the chip. This is the same
> here. If I know that the chip does not send me what it receives
> when configured in promiscuous mode, I can I swear it never received
> the missing packet ? There's always a doubt. Maybe sometimes the
> filter is buggy, maybe it only passes tags when the remaining bits
> are all zero, etc... Promiscuous mode generally means that you're
> the closest possible to the wire. We already do not receive pause
> frames and sometimes that's annoying. But having no control over
> what we want to see is frustrating.
> 
> 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 really do not want to add another module parameter to the driver for this. It
seems bogus as well: if we can agree on one sane choice it's much better, and if
we don't then we should use ethtool to provide a uniform way of implementing this
for all drivers sanely.

Auke

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

  reply	other threads:[~2007-11-12 23:40 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-11  0:51 [PATCH 2/2] [e1000 VLAN] Disable vlan hw accel when promiscuous mode Joonwoo Park
2007-11-11  0:51 ` Joonwoo Park
2007-11-12 17:12 ` Kok, Auke
2007-11-12 17:21   ` Patrick McHardy
2007-11-12 17:21     ` Patrick McHardy
2007-11-12 18:01     ` [E1000-devel] " Kok, Auke
2007-11-12 18:01       ` Kok, Auke
2007-11-12 22:33     ` David Miller
2007-11-12 22:33       ` David Miller
2007-11-12 22:43       ` Chris Friesen
2007-11-12 22:54         ` Kok, Auke
2007-11-12 22:54           ` Kok, Auke
2007-11-14 11:48           ` Benny Amorsen
2007-11-14 11:48             ` Benny Amorsen
2007-11-12 22:57         ` David Miller
2007-11-12 22:57           ` David Miller
2007-11-12 23:15           ` Willy Tarreau
2007-11-12 23:15             ` Willy Tarreau
2007-11-12 23:19             ` David Miller
2007-11-12 23:19               ` David Miller
2007-11-12 23:32               ` Willy Tarreau
2007-11-12 23:32                 ` Willy Tarreau
2007-11-12 23:38                 ` Kok, Auke [this message]
2007-11-12 23:38                   ` Kok, Auke
2007-11-12 23:40                 ` David Miller
2007-11-12 23:40                   ` David Miller
2007-11-13  1:21                   ` Joonwoo Park
2007-11-13  1:21                     ` Joonwoo Park
2007-11-13 10:21                     ` Patrick McHardy
2007-11-13 11:09                       ` Herbert Xu
2007-11-13 11:36                         ` David Miller
2007-11-13 11:36                           ` David Miller
2007-11-13 12:03                           ` Herbert Xu
2007-11-13 12:06                             ` David Miller
2007-11-13 12:16                               ` Herbert Xu
2007-11-13 12:18                                 ` Patrick McHardy
2007-11-13 16:41                                   ` Kok, Auke
2007-11-13 16:41                                     ` Kok, Auke
2007-11-13 17:26                                     ` Patrick McHardy
2007-11-13 17:26                                       ` Patrick McHardy
2007-11-13 17:30                                       ` Kok, Auke
2007-11-13 17:30                                         ` Kok, Auke
2007-11-14  9:42                                         ` Patrick McHardy
2007-11-14 23:30                                           ` Kok, Auke
2007-11-14 23:30                                             ` Kok, Auke
2007-11-13 19:59                                       ` Kok, Auke
2007-11-13 12:32                                 ` David Miller
2007-11-13 12:32                                   ` David Miller
2007-11-13  1:21             ` Joonwoo Park
2007-11-12 22:28   ` David Miller
2007-11-12 22:28     ` David Miller
2007-11-13 20:43 ` Stephen Hemminger
2007-11-13 20:43   ` Stephen Hemminger
  -- strict thread matches above, loose matches on Subject: below --
2007-11-14  4:47 Joonwoo Park
2007-11-14  4:47 ` Joonwoo Park
2007-11-14  5:12 ` Kok, Auke
2007-11-14  5:12   ` Kok, Auke
2007-11-14  6:15   ` Joonwoo Park
2007-11-14  6:15     ` Joonwoo Park

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=4738E404.8020105@intel.com \
    --to=auke-jan.h.kok@intel.com \
    --cc=cfriesen@nortel.com \
    --cc=davem@davemloft.net \
    --cc=djohnson+linux-kernel@sw.starentnetworks.com \
    --cc=e1000-devel@lists.sourceforge.net \
    --cc=joonwpark81@gmail.com \
    --cc=kaber@trash.net \
    --cc=linux-kernel@vger.kernel.org \
    --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.