[ovs-git] [openvswitch/ovs] 27521c: datapath: do not propagate headroom updates to int...

GitHub noreply at github.com
Fri Feb 16 08:49:57 UTC 2018


  Branch: refs/heads/branch-2.8
  Home:   https://github.com/openvswitch/ovs
  Commit: 27521ce4c7d2177a36fc676851c4aa9e04bb2872
      https://github.com/openvswitch/ovs/commit/27521ce4c7d2177a36fc676851c4aa9e04bb2872
  Author: paolo abeni <pabeni at redhat.com>
  Date:   2018-02-16 (Fri, 16 Feb 2018)

  Changed paths:
    M datapath/vport-internal_dev.c

  Log Message:
  -----------
  datapath: do not propagate headroom updates to internal port

Upstream commit:
    commit 183dea5818315c0a172d21ecbcd2554894bf01e3
    Author: Paolo Abeni <pabeni at redhat.com>
    Date:   Thu Nov 30 15:35:33 2017 +0100

    openvswitch: do not propagate headroom updates to internal port

    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 at redhat.com>
    Acked-by: Pravin B Shelar <pshelar at ovn.org>
    Signed-off-by: David S. Miller <davem at davemloft.net>

Cc: paolo abeni <pabeni at redhat.com>
Signed-off-by: Greg Rose <gvrose8192 at gmail.com>
Acked-by: Pravin B Shelar <pshelar at ovn.org>


  Commit: 33624929f0e25c3994eb1ef15fbfa90a234b416b
      https://github.com/openvswitch/ovs/commit/33624929f0e25c3994eb1ef15fbfa90a234b416b
  Author: Eric Garver <e at erig.me>
  Date:   2018-02-16 (Fri, 16 Feb 2018)

  Changed paths:
    M datapath/flow.c

  Log Message:
  -----------
  datapath: Fix pop_vlan action for double tagged frames

Upstream commit:
    commit c48e74736fccf25fb32bb015426359e1c2016e3b
    Author: Eric Garver <e at erig.me>
    Date:   Wed Dec 20 15:09:22 2017 -0500

    openvswitch: Fix pop_vlan action for double tagged frames

    skb_vlan_pop() expects skb->protocol to be a valid TPID for double
    tagged frames. So set skb->protocol to the TPID and let skb_vlan_pop()
    shift the true ethertype into position for us.

    Fixes: 5108bbaddc37 ("openvswitch: add processing of L3 packets")
    Signed-off-by: Eric Garver <e at erig.me>
    Reviewed-by: Jiri Benc <jbenc at redhat.com>
    Signed-off-by: David S. Miller <davem at davemloft.net>

Cc: Eric Garver <e at erig.me>
Fixes: a27c454ee0 ("datapath: add processing of L3 packets")
Signed-off-by: Greg Rose <gvrose8192 at gmail.com>
Acked-by: Pravin B Shelar <pshelar at ovn.org>


  Commit: 17f51c6a96e79b092aa8b03b60986c0ba8b31c10
      https://github.com/openvswitch/ovs/commit/17f51c6a96e79b092aa8b03b60986c0ba8b31c10
  Author: Ed Swierk <eswierk at skyportsystems.com>
  Date:   2018-02-16 (Fri, 16 Feb 2018)

  Changed paths:
    M datapath/conntrack.c

  Log Message:
  -----------
  datapath: Remove padding from packet before L3+ conntrack processing

Upstream commit:
    commit 9382fe71c0058465e942a633869629929102843d
    Author: Ed Swierk <eswierk at skyportsystems.com>
    Date:   Wed Jan 31 18:48:02 2018 -0800

    openvswitch: Remove padding from packet before L3+ conntrack processing

    IPv4 and IPv6 packets may arrive with lower-layer padding that is not
    included in the L3 length. For example, a short IPv4 packet may have
    up to 6 bytes of padding following the IP payload when received on an
    Ethernet device with a minimum packet length of 64 bytes.

    Higher-layer processing functions in netfilter (e.g. nf_ip_checksum(),
    and help() in nf_conntrack_ftp) assume skb->len reflects the length of
    the L3 header and payload, rather than referring back to
    ip_hdr->tot_len or ipv6_hdr->payload_len, and get confused by
    lower-layer padding.

    In the normal IPv4 receive path, ip_rcv() trims the packet to
    ip_hdr->tot_len before invoking netfilter hooks. In the IPv6 receive
    path, ip6_rcv() does the same using ipv6_hdr->payload_len. Similarly
    in the br_netfilter receive path, br_validate_ipv4() and
    br_validate_ipv6() trim the packet to the L3 length before invoking
    netfilter hooks.

    Currently in the OVS conntrack receive path, ovs_ct_execute() pulls
    the skb to the L3 header but does not trim it to the L3 length before
    calling nf_conntrack_in(NF_INET_PRE_ROUTING). When
    nf_conntrack_proto_tcp encounters a packet with lower-layer padding,
    nf_ip_checksum() fails causing a "nf_ct_tcp: bad TCP checksum" log
    message. While extra zero bytes don't affect the checksum, the length
    in the IP pseudoheader does. That length is based on skb->len, and
    without trimming, it doesn't match the length the sender used when
    computing the checksum.

    In ovs_ct_execute(), trim the skb to the L3 length before higher-layer
    processing.

    Signed-off-by: Ed Swierk <eswierk at skyportsystems.com>
    Acked-by: Pravin B Shelar <pshelar at ovn.org>
    Signed-off-by: David S. Miller <davem at davemloft.net>

Cc: Ed Swierk <eswierk at skyportsystems.com>
Signed-off-by: Greg Rose <gvrose8192 at gmail.com>
Acked-by: Pravin B Shelar <pshelar at ovn.org>


Compare: https://github.com/openvswitch/ovs/compare/dbc6cbc08abe...17f51c6a96e7


More information about the git mailing list