From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 661FEC432C3 for ; Thu, 14 Nov 2019 05:03:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 54891206EC for ; Thu, 14 Nov 2019 05:03:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725903AbfKNFDf (ORCPT ); Thu, 14 Nov 2019 00:03:35 -0500 Received: from relay12.mail.gandi.net ([217.70.178.232]:48927 "EHLO relay12.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725267AbfKNFDf (ORCPT ); Thu, 14 Nov 2019 00:03:35 -0500 Received: from mail-vs1-f45.google.com (mail-vs1-f45.google.com [209.85.217.45]) (Authenticated sender: pshelar@ovn.org) by relay12.mail.gandi.net (Postfix) with ESMTPSA id 7A60D200002 for ; Thu, 14 Nov 2019 05:03:33 +0000 (UTC) Received: by mail-vs1-f45.google.com with SMTP id m6so3004038vsn.13 for ; Wed, 13 Nov 2019 21:03:33 -0800 (PST) X-Gm-Message-State: APjAAAVk+ZCU6YS/VqEmsLfr6asoxLUFT1L9qPAg2VUr9k2jX0dmLftp pWPe+T7lklVpWsFKUIAeLfRKKIhk6/PLBzekcZM= X-Google-Smtp-Source: APXvYqxTzPkK5Dsfu325XMD6wodZCIhukd8E0JtZ08U2a039WKMjPj/q/Aa0wAMXDYH3p7j1an8aMicP8Ybv1fmvIlI= X-Received: by 2002:a67:6e05:: with SMTP id j5mr4712767vsc.66.1573707811617; Wed, 13 Nov 2019 21:03:31 -0800 (PST) MIME-Version: 1.0 References: <1573657489-16067-1-git-send-email-xiangxia.m.yue@gmail.com> In-Reply-To: <1573657489-16067-1-git-send-email-xiangxia.m.yue@gmail.com> From: Pravin Shelar Date: Wed, 13 Nov 2019 21:03:22 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH net-next v4] net: openvswitch: add hash info to upcall To: Tonghao Zhang Cc: Greg Rose , Ben Pfaff , Linux Kernel Network Developers , ovs dev Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, Nov 13, 2019 at 7:05 AM wrote: > > From: Tonghao Zhang > > When using the kernel datapath, the upcall don't > include skb hash info relatived. That will introduce > some problem, because the hash of skb is important > in kernel stack. For example, VXLAN module uses > it to select UDP src port. The tx queue selection > may also use the hash in stack. > > Hash is computed in different ways. Hash is random > for a TCP socket, and hash may be computed in hardware, > or software stack. Recalculation hash is not easy. > > Hash of TCP socket is computed: > tcp_v4_connect > -> sk_set_txhash (is random) > > __tcp_transmit_skb > -> skb_set_hash_from_sk > > There will be one upcall, without information of skb > hash, to ovs-vswitchd, for the first packet of a TCP > session. The rest packets will be processed in Open vSwitch > modules, hash kept. If this tcp session is forward to > VXLAN module, then the UDP src port of first tcp packet > is different from rest packets. > > TCP packets may come from the host or dockers, to Open vSwitch. > To fix it, we store the hash info to upcall, and restore hash > when packets sent back. > > +---------------+ +-------------------------+ > | Docker/VMs | | ovs-vswitchd | > +----+----------+ +-+--------------------+--+ > | ^ | > | | | > | | upcall v restore packet hash (not recalculate) > | +-+--------------------+--+ > | tap netdev | | vxlan module > +---------------> +--> Open vSwitch ko +--> > or internal type | | > +-------------------------+ > > Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2019-October/364062.html > Signed-off-by: Tonghao Zhang Acked-by: Pravin B Shelar Thanks.