netdev - Re: [PATCH net-next] openvswitch: do not propagate headroom updates to internal port

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 1 Dec 2017 14:58:04 -0800
From:   Pravin Shelar <pshelar@....org>
To:     Paolo Abeni <pabeni@...hat.com>
Cc:     Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Pravin Shelar <pshelar@...ira.com>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH net-next] openvswitch: do not propagate headroom updates
 to internal port

On Thu, Nov 30, 2017 at 6:35 AM, Paolo Abeni <pabeni@...hat.com> wrote:
> After commit 3a927bc7cf9d ("ovs: propagate per dp max headroom to
> all vports") the need_headroom for the internal vport is updated
> accordingly to the max needed headroom in its datapath.
>
> That avoids the pskb_expand_head() costs when sending/forwarding
> packets towards tunnel devices, at least for some scenarios.
>
> We still require such copy when using the ovs-preferred configuration
> for vxlan tunnels:
>
>     br_int
>   /       \
> tap      vxlan
>            (remote_ip:X)
>
> br_phy
>      \
>     NIC
>
> where the route towards the IP 'X' is via 'br_phy'.
>
> When forwarding traffic from the tap towards the vxlan device, we
> will call pskb_expand_head() in vxlan_build_skb() because
> br-phy->needed_headroom is equal to tun->needed_headroom.
>
> With this change we avoid updating the internal vport needed_headroom,
> so that in the above scenario no head copy is needed, giving 5%
> performance improvement in UDP throughput test.
>
> As a trade-off, packets sent from the internal port towards a tunnel
> device will now experience the head copy overhead. The rationale is
> that the latter use-case is less relevant performance-wise.
>
> Signed-off-by: Paolo Abeni <pabeni@...hat.com>

Acked-by: Pravin B Shelar <pshelar@....org>

Thanks.