Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp692189ybc; Tue, 12 Nov 2019 07:48:43 -0800 (PST) X-Google-Smtp-Source: APXvYqxfWaKZLlROSVrv9AT+q66p2YH3MXagU7mUcSaFrzKd6ylzZZO6IODshOJxu/4DglNuX0Fu X-Received: by 2002:a50:a7a1:: with SMTP id i30mr33076148edc.94.1573573723443; Tue, 12 Nov 2019 07:48:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573573723; cv=none; d=google.com; s=arc-20160816; b=ZfRccVqUDTeAxe1TZD5wUMw7CMQCXbPUf8fboGsKou8QgtN5Of4DBgmUQXb710ANpK G3HDdnZxNSUNNYlk+mHg6VEczWlUd5m1P6FFTCryroXDQM0NmTydayTHaGE2r6BZhqm3 Y4xqACstR8v7pAAcK7Iom4xiACHAA+lkYogL8lTnWMZT/tJMwgFDDm4txB4/TldP+2Jt Il7G68yianY9QjmOH9lWyZgaZwhTovdjRYR0ImlcFmtTZBY1sNJVLXBNl461cwAplyeX tH0LV6XzLUS6nw7sEqmZfIUHvEqRB9kOYYDVouz3P7datjEEhJ6PsN4Lh3EfS/hhUrvZ hmWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=TrgtIcC3Ha1/0dzS1VtlsAm2hMfZJyX2cxwGUaWtbv4=; b=bTsvvEInrgOZemoKqDXa8/93CKD2ixSu2QSRzLlCgF/0DGezQICeRJidAfDj6USBI9 x2v4nZnV3W8mRpbfEKfwMvzDlc1Oz2X1wfjLJG0tT2re4yZZsjCnRxf0FI8+j6gj/nq3 l7gNV1OhaxLsgcXskmg9RdD+95R+Cg6EjIXs/33yg38vx1n25ul0Bop9HSS/+4QKcVZX AcgW6lI4Y71Mk3SCLoYqRxwIRmIbVgwFH3Je7JaT4HeeRoqAvbFVGY/K7xBR3Virbg63 Zhpcz4wCLdGR9mZuYD1y1LgNXeRfY+kmSt3hBsfGt7PiaeEfeEv6pWm4+i3PJ58Wsz78 Q58A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=hcZHg0bQ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w47si14197796edd.326.2019.11.12.07.48.17; Tue, 12 Nov 2019 07:48:43 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=hcZHg0bQ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727413AbfKLPqz (ORCPT + 99 others); Tue, 12 Nov 2019 10:46:55 -0500 Received: from us-smtp-1.mimecast.com ([205.139.110.61]:58858 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725954AbfKLPqy (ORCPT ); Tue, 12 Nov 2019 10:46:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573573613; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TrgtIcC3Ha1/0dzS1VtlsAm2hMfZJyX2cxwGUaWtbv4=; b=hcZHg0bQI3w65Z1RWs89QVM5RE1/RsD5s8YE+YewhPMJgAUlgD8HTYg/l3/1MJQBJe2mtg moOkykmOAUht1JwA67xswg01sUEwyXaj5Osq+I8OM6U+wty7+tfZ+tmxNj2bfQ+tBFrO+r OK6o8pLDnhmGgZDiBPhJ9GL/PqXRsls= Received: from mail-lf1-f69.google.com (mail-lf1-f69.google.com [209.85.167.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-82-1AOv6F6nOuKRtDw0Z1t5Gg-1; Tue, 12 Nov 2019 10:46:50 -0500 Received: by mail-lf1-f69.google.com with SMTP id u14so1207067lfk.7 for ; Tue, 12 Nov 2019 07:46:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G/51mof5846DapZXCI9+0p5WNkNYG968g1sxSQhoVUs=; b=AzQ7tlplW1T8RNLL04BVLxq6WNOvoT1rulaK+MeYrM5tFSGV8Vqv5wyaPKWkyEWKZu mo3GqefInPukZGuN6Xq2FK8UVqQHw9pYtMQdnEjDT3rR3XFqSPU5aNl16t5Ann1qdska G/kGqKWVsb8sLToY02olM4931s9wuv9JtbwNDh6Payo3ABkuTHh+PCmFuto8YgUqJQBG 4QRadB/CQS1H/xP0e+uibxqYgPeDa16+2YAsf+lZkw8KiFPQGQr5looO4KFtzBkzFmgg lHvEs24n8exUjEr50LDdlxRzG3aPLy4CPUYTTiB16RQCkNzPZnFjw49Pabi4GJtYwG03 nO/Q== X-Gm-Message-State: APjAAAWS7h7YUA+5tGKa1HRii3zotBZUYU1287XNY3l4GfAnkErP7wgu b2GeYN7v+TbhTqXnqo5HLzNikPXCiETdY5/dzeI61bEEYrP3oduB26gjGzf0qfX7Oh66MzaD2wx OaKekQab1GuOXNdRFq9IbYlnlHvOSNt0PQ//0Mb0J X-Received: by 2002:a19:22c4:: with SMTP id i187mr18628824lfi.152.1573573609118; Tue, 12 Nov 2019 07:46:49 -0800 (PST) X-Received: by 2002:a19:22c4:: with SMTP id i187mr18628802lfi.152.1573573608866; Tue, 12 Nov 2019 07:46:48 -0800 (PST) MIME-Version: 1.0 References: <20191112102518.4406-1-mcroce@redhat.com> <20191112150046.2aehmeoq7ri6duwo@netronome.com> In-Reply-To: <20191112150046.2aehmeoq7ri6duwo@netronome.com> From: Matteo Croce Date: Tue, 12 Nov 2019 16:46:12 +0100 Message-ID: Subject: Re: [PATCH net-next] openvswitch: add TTL decrement action To: Simon Horman Cc: netdev , dev@openvswitch.org, LKML , Pravin B Shelar , "David S. Miller" , Bindiya Kurle X-MC-Unique: 1AOv6F6nOuKRtDw0Z1t5Gg-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 12, 2019 at 4:00 PM Simon Horman w= rote: > > On Tue, Nov 12, 2019 at 11:25:18AM +0100, Matteo Croce wrote: > > New action to decrement TTL instead of setting it to a fixed value. > > This action will decrement the TTL and, in case of expired TTL, send th= e > > packet to userspace via output_userspace() to take care of it. > > > > Supports both IPv4 and IPv6 via the ttl and hop_limit fields, respectiv= ely. > > > > Usually OVS achieves this behaviour by matching on the TTL and > setting it to the desired value, pre-calculated as TTL -1. > With that in mind could you explain the motivation for this > change? > Hi, the problem is that OVS creates a flow for each ttl it see. I can let vswitchd create 255 flows with like this: $ for i in {2..255}; do ping 192.168.0.2 -t $i -c1 -w1 &>/dev/null & done $ ovs-dpctl dump-flows |fgrep -c 'set(ipv4(ttl' 255 > > @@ -1174,6 +1174,43 @@ static int execute_check_pkt_len(struct datapath= *dp, struct sk_buff *skb, > > nla_len(actions), last, clone_flow_key); > > } > > > > +static int execute_dec_ttl(struct sk_buff *skb, struct sw_flow_key *ke= y) > > +{ > > + int err; > > + > > + if (skb->protocol =3D=3D htons(ETH_P_IPV6)) { > > + struct ipv6hdr *nh =3D ipv6_hdr(skb); > > + > > + err =3D skb_ensure_writable(skb, skb_network_offset(skb) = + > > + sizeof(*nh)); > > + if (unlikely(err)) > > + return err; > > + > > + if (nh->hop_limit <=3D 1) > > + return -EHOSTUNREACH; > > + > > + key->ip.ttl =3D --nh->hop_limit; > > + } else { > > + struct iphdr *nh =3D ip_hdr(skb); > > + u8 old_ttl; > > + > > + err =3D skb_ensure_writable(skb, skb_network_offset(skb) = + > > + sizeof(*nh)); > > + if (unlikely(err)) > > + return err; > > + > > + if (nh->ttl <=3D 1) > > + return -EHOSTUNREACH; > > + > > + old_ttl =3D nh->ttl--; > > + csum_replace2(&nh->check, htons(old_ttl << 8), > > + htons(nh->ttl << 8)); > > + key->ip.ttl =3D nh->ttl; > > + } > > The above may send packets with TTL =3D 0, is that desired? > If TTL is 1 or 0, execute_dec_ttl() returns -EHOSTUNREACH, and the caller will just send the packet to userspace and then free it. I think this is enough, am I missing something? Bye, --=20 Matteo Croce per aspera ad upstream