All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: Stephen Hemminger <shemminger@linux-foundation.org>
Cc: netdev@vger.kernel.org, bridge@linux-foundation.org,
	David Miller <davem@davemloft.net>
Subject: Re: [Bridge] [PATCH] bridge: avoid ptype_all packet handling
Date: Wed, 28 Feb 2007 20:05:10 -0800	[thread overview]
Message-ID: <45E650F6.4030404@candelatech.com> (raw)
In-Reply-To: <20070228195611.24cf19ee@deepthought>

Stephen Hemminger wrote:
> On Wed, 28 Feb 2007 17:28:09 -0800
> Ben Greear <greearb@candelatech.com> wrote:
>
>   
>> Stephen Hemminger wrote:
>>     
>>> I was measuring bridging/routing performance and noticed this.
>>>
>>> The current code runs the "all packet" type handlers before calling
>>> the bridge hook.  If an application (like some DHCP clients) is
>>> using AF_PACKET, this means that each received packet gets run
>>> through the Berkeley Packet Filter code in sk_run_filter (slow).
>>>
>>> By moving the bridging hook to run first, the packets flowing
>>> through the bridge get filtered out there. This results in a 14%
>>> improvement in performance, but it does mean that some snooping
>>> applications would miss packets if being used on a bridge.  The
>>> correct way to see all packets on a bridge is to set the bridge
>>> pseudo-device to promiscuous mode.
>>>       
>> Seems it would be better to fix these clients to be more selective as
>> to where they bind.
>>     
>
> The problem is any use of BPF is a lose, if it has to be done to all
> traffic.
>   
Right, but couldn't you have the dhcp client bind to eth0, eth7, and br0 
(ie, skipping the eth1-6 that comprise the bridge group?)

The only difficulty I see is having the client know when new devices 
come and go, but there are probably
ways to know that without keeping a whole lot of state or probing the 
/proc/net/dev (like my own bloated app does :))

I envision the client args to be something like --skip-devices "eth1 
eth2 eth3 ..."

I know you can bind raw packet sockets to individual devices, though I 
don't know much about BPF, so it's
possible I'm wrong...

>> This breaks the case where you want to see packets on a particular
>> interface, not just the entire bridge, right?
>>     
>
> It might be possible to use promisc counter to handle this.
>   
Not really, it's perfectly valid to sniff a port in non-promiscuous mode...

Ben

> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   


-- 
Ben Greear <greearb@candelatech.com> 
Candela Technologies Inc  http://www.candelatech.com



WARNING: multiple messages have this Message-ID (diff)
From: Ben Greear <greearb@candelatech.com>
To: Stephen Hemminger <shemminger@linux-foundation.org>
Cc: David Miller <davem@davemloft.net>,
	bridge@linux-foundation.org, netdev@vger.kernel.org
Subject: Re: [PATCH] bridge: avoid ptype_all packet handling
Date: Wed, 28 Feb 2007 20:05:10 -0800	[thread overview]
Message-ID: <45E650F6.4030404@candelatech.com> (raw)
In-Reply-To: <20070228195611.24cf19ee@deepthought>

Stephen Hemminger wrote:
> On Wed, 28 Feb 2007 17:28:09 -0800
> Ben Greear <greearb@candelatech.com> wrote:
>
>   
>> Stephen Hemminger wrote:
>>     
>>> I was measuring bridging/routing performance and noticed this.
>>>
>>> The current code runs the "all packet" type handlers before calling
>>> the bridge hook.  If an application (like some DHCP clients) is
>>> using AF_PACKET, this means that each received packet gets run
>>> through the Berkeley Packet Filter code in sk_run_filter (slow).
>>>
>>> By moving the bridging hook to run first, the packets flowing
>>> through the bridge get filtered out there. This results in a 14%
>>> improvement in performance, but it does mean that some snooping
>>> applications would miss packets if being used on a bridge.  The
>>> correct way to see all packets on a bridge is to set the bridge
>>> pseudo-device to promiscuous mode.
>>>       
>> Seems it would be better to fix these clients to be more selective as
>> to where they bind.
>>     
>
> The problem is any use of BPF is a lose, if it has to be done to all
> traffic.
>   
Right, but couldn't you have the dhcp client bind to eth0, eth7, and br0 
(ie, skipping the eth1-6 that comprise the bridge group?)

The only difficulty I see is having the client know when new devices 
come and go, but there are probably
ways to know that without keeping a whole lot of state or probing the 
/proc/net/dev (like my own bloated app does :))

I envision the client args to be something like --skip-devices "eth1 
eth2 eth3 ..."

I know you can bind raw packet sockets to individual devices, though I 
don't know much about BPF, so it's
possible I'm wrong...

>> This breaks the case where you want to see packets on a particular
>> interface, not just the entire bridge, right?
>>     
>
> It might be possible to use promisc counter to handle this.
>   
Not really, it's perfectly valid to sniff a port in non-promiscuous mode...

Ben

> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   


-- 
Ben Greear <greearb@candelatech.com> 
Candela Technologies Inc  http://www.candelatech.com



  reply	other threads:[~2007-03-01  4:05 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-01  1:18 [Bridge] [PATCH] bridge: avoid ptype_all packet handling Stephen Hemminger
2007-03-01  1:18 ` Stephen Hemminger
2007-03-01  1:28 ` [Bridge] " Ben Greear
2007-03-01  1:28   ` Ben Greear
2007-03-01  3:56   ` [Bridge] " Stephen Hemminger
2007-03-01  3:56     ` Stephen Hemminger
2007-03-01  4:05     ` Ben Greear [this message]
2007-03-01  4:05       ` Ben Greear
2007-03-01  7:04       ` [Bridge] " Stephen Hemminger
2007-03-01  7:04         ` Stephen Hemminger
2007-03-01  7:22         ` [Bridge] " David Miller
2007-03-01  7:22           ` David Miller
2007-03-01  7:26           ` [Bridge] " Stephen Hemminger
2007-03-01  7:26             ` Stephen Hemminger
2007-03-01  7:30             ` [Bridge] " David Miller
2007-03-01  7:30               ` David Miller
2007-03-01 11:47               ` [Bridge] " jamal
2007-03-01 11:47                 ` jamal
2007-03-03  2:14               ` [Bridge] " Andi Kleen
2007-03-03  2:14                 ` Andi Kleen
2007-03-03  4:22                 ` [Bridge] " David Miller
2007-03-03  4:22                   ` David Miller
2007-03-03  7:09                   ` [Bridge] " Stephen Hemminger
2007-03-03  7:09                     ` Stephen Hemminger
2007-03-03 12:30                   ` [Bridge] " Andi Kleen
2007-03-03 12:30                     ` Andi Kleen
2007-03-02 21:26 ` [Bridge] " David Miller
2007-03-02 21:26   ` David Miller
2007-03-02 22:09   ` [Bridge] [RFC 1/2] " Stephen Hemminger
2007-03-02 22:09     ` Stephen Hemminger
2007-03-02 22:14     ` [Bridge] [RFC 2/2] bridge: per device promiscious taps Stephen Hemminger
2007-03-02 22:14       ` Stephen Hemminger
2007-03-02 22:48     ` [Bridge] [RFC 1/2] bridge: avoid ptype_all packet handling David Miller
2007-03-02 22:48       ` David Miller
2007-03-02 23:18       ` [Bridge] " David Miller
2007-03-02 23:18         ` David Miller
2007-03-02 23:34         ` [Bridge] " Stephen Hemminger
2007-03-02 23:34           ` Stephen Hemminger
2007-03-02 23:41           ` [Bridge] " David Miller
2007-03-02 23:41             ` David Miller
2007-03-03  5:38         ` [Bridge] " Herbert Xu
2007-03-03  5:38           ` Herbert Xu
2007-03-03  5:59           ` [Bridge] " David Miller
2007-03-03  5:59             ` David Miller
2007-03-03  6:42             ` [Bridge] " Herbert Xu
2007-03-03  6:42               ` Herbert Xu
2007-03-02 22:15   ` [Bridge] " Stephen Hemminger
2007-03-02 22:15     ` Stephen Hemminger
2007-03-03 12:04   ` [Bridge] [PATCH] " Stefan Rompf
2007-03-03 12:04     ` Stefan Rompf

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=45E650F6.4030404@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=bridge@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@linux-foundation.org \
    /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.