netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Lobakin <alobakin@pm.me>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Alexander Lobakin <alobakin@pm.me>,
	netfilter-devel@vger.kernel.org, davem@davemloft.net,
	netdev@vger.kernel.org, kuba@kernel.org, fw@strlen.de,
	razor@blackwall.org, jeremy@azazel.net, tobias@waldekranz.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next,v5 0/9] netfilter: flowtable bridge and vlan enhancements
Date: Sun, 22 Nov 2020 14:51:18 +0000	[thread overview]
Message-ID: <20201122145108.2640-1-alobakin@pm.me> (raw)
In-Reply-To: <20201122102605.2342-1-alobakin@pm.me>

From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Sun, 22 Nov 2020 12:42:19 +0100

> On Sun, Nov 22, 2020 at 10:26:16AM +0000, Alexander Lobakin wrote:
>> From: Pablo Neira Ayuso <pablo@netfilter.org>
>> Date: Fri, 20 Nov 2020 13:49:12 +0100
> [...]
>>> Something like this:
>>>
>>>                        fast path
>>>                 .------------------------.
>>>                /                          \
>>>                |           IP forwarding   |
>>>                |          /             \  .
>>>                |       br0               eth0
>>>                .       / \
>>>                -- veth1  veth2
>>>                    .
>>>                    .
>>>                    .
>>>                  eth0
>>>            ab:cd:ef:ab:cd:ef
>>>                   VM
>>
>> I'm concerned about bypassing vlan and bridge's .ndo_start_xmit() in
>> case of this shortcut. We'll have incomplete netdevice Tx stats for
>> these two, as it gets updated inside this callbacks.
>
> TX device stats are being updated accordingly.
>
> # ip netns exec nsr1 ip -s link
> 1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>     RX: bytes  packets  errors  dropped overrun mcast   
>     0          0        0       0       0       0       
>     TX: bytes  packets  errors  dropped carrier collsns 
>     0          0        0       0       0       0       
> 2: veth0@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
>     link/ether 82:0d:f3:b5:59:5d brd ff:ff:ff:ff:ff:ff link-netns ns1
>     RX: bytes  packets  errors  dropped overrun mcast   
>     213290848248 4869765  0       0       0       0       
>     TX: bytes  packets  errors  dropped carrier collsns 
>     315346667  4777953  0       0       0       0       
> 3: veth1@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
>     link/ether 4a:81:2d:9a:02:88 brd ff:ff:ff:ff:ff:ff link-netns ns2
>     RX: bytes  packets  errors  dropped overrun mcast   
>     315337919  4777833  0       0       0       0       
>     TX: bytes  packets  errors  dropped carrier collsns 
>     213290844826 4869708  0       0       0       0       
> 4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
>     link/ether 82:0d:f3:b5:59:5d brd ff:ff:ff:ff:ff:ff
>     RX: bytes  packets  errors  dropped overrun mcast   
>     4101       73       0       0       0       0       
>     TX: bytes  packets  errors  dropped carrier collsns 
>     5256       74       0       0       0       0       

Aren't these counters very low for br0, despite that br0 is an
intermediate point of traffic flow?

> 5: veth0.10@veth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP mode DEFAULT group default qlen 1000
>     link/ether 82:0d:f3:b5:59:5d brd ff:ff:ff:ff:ff:ff
>     RX: bytes  packets  errors  dropped overrun mcast   
>     4101       73       0       0       0       62      
>     TX: bytes  packets  errors  dropped carrier collsns 
>     315342363  4777893  0       0       0       0       


  parent reply	other threads:[~2020-11-22 14:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-22 10:26 [PATCH net-next,v5 0/9] netfilter: flowtable bridge and vlan enhancements Alexander Lobakin
2020-11-22 11:42 ` Pablo Neira Ayuso
2020-11-22 14:51 ` Alexander Lobakin [this message]
2020-11-22 20:15   ` Pablo Neira Ayuso
  -- strict thread matches above, loose matches on Subject: below --
2020-11-20 15:09 Alexander Lobakin
2020-11-21 11:58 ` Pablo Neira Ayuso
2020-11-20 12:49 Pablo Neira Ayuso

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=20201122145108.2640-1-alobakin@pm.me \
    --to=alobakin@pm.me \
    --cc=davem@davemloft.net \
    --cc=fw@strlen.de \
    --cc=jeremy@azazel.net \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=razor@blackwall.org \
    --cc=tobias@waldekranz.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).