From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 60C5D3CB35 for ; Fri, 8 Mar 2019 06:28:16 -0500 (EST) Received: by mail-ed1-f54.google.com with SMTP id g19so16145142edp.2 for ; Fri, 08 Mar 2019 03:28:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=cF3l/qZpB+laIXfR+RKM2bvv0p4PLbA5k5f2sOxIK5U=; b=uCfRRyzF5ifO+GY1gjHK3phPA6WrgkMolfRKBNxM/VPlO671ID3aGtACufr22WW6Go kIZQAyZAtTvvvenGCp3ScQQA+Uk+VcKmqe125eYV7K90TzwltlbCRbBK1ALQFZvGIvQP L4IE/MBSci42/8T31Fp+JCBiw5t586c7GhNxals0lAAGhLdcX8j+sps1YyYT1dNv/cO6 ru/3oe0tBS4YL+i4eRie/C3EX6K6n/IUJCRfq6kAw4/PcDON2XdYFt5mXWGzZ9xKNrMh q60vKk2bO+Zd/4JmSYQqzZZvx5/pH1rhWx6lnZK33Wib5yo9ZUgBjAXKM4rbh4fTD24M roig== X-Gm-Message-State: APjAAAUOoBNFqpr3x3c8zXqd411qdGYBXsZh64kxv+/P8vnE2UswQt1M CKEJ1HMZ3g0HbvouVDpqJLGqkcqvHm0= X-Google-Smtp-Source: APXvYqyjG0RZbcFta6zC6P68eljwi8mc+uLyYobJ0XQ4+3tg/eSbjTBfZDsfkojoKPBy2mHOK6e3pA== X-Received: by 2002:a50:a484:: with SMTP id w4mr31761486edb.193.1552044495488; Fri, 08 Mar 2019 03:28:15 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk ([2a00:7660:6da:10::2]) by smtp.gmail.com with ESMTPSA id h22sm1360374ejj.43.2019.03.08.03.28.14 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 08 Mar 2019 03:28:15 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 9F40718049E; Fri, 8 Mar 2019 12:28:09 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Kevin Darbyshire-Bryant Cc: "cake\@lists.bufferbloat.net" In-Reply-To: <00E839ED-7FA4-4577-838F-775EC9A90608@darbyshire-bryant.me.uk> References: <875zsw110r.fsf@toke.dk> <6B530473-971A-4265-B94B-3595D39D57AF@darbyshire-bryant.me.uk> <87r2bjyoyn.fsf@toke.dk> <4505E3A0-6AE2-4C0B-960D-B1EDB616F0CA@darbyshire-bryant.me.uk> <878sxq1t3e.fsf@toke.dk> <00E839ED-7FA4-4577-838F-775EC9A90608@darbyshire-bryant.me.uk> X-Clacks-Overhead: GNU Terry Pratchett Date: Fri, 08 Mar 2019 12:28:09 +0100 Message-ID: <871s3h7ghi.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] act_connmark + dscp X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 11:28:16 -0000 Kevin Darbyshire-Bryant writes: > On its own I don=E2=80=99t think that would work for ingress traffic - > iptables happens too late. So on planet Kevin I still need some sort > of flag held in the fwmark that says =E2=80=98I hold a DSCP value=E2=80= =99 so cake can > use it and act_connmarkdscp can (optionally) restore it to the > diffserv field. > > I suspect we=E2=80=99re going around in circles around what I would like = which > is =E2=80=9Ca bit DSCP fuzzy but lighter on CPU =E2=80=98cos I don=E2=80= =99t have to hit > iptables mangle rules as much=E2=80=9D v what I think you would like is > =E2=80=99update the fwmark DSCP every time but that also requires iptable= s to > mangle the DSCP for every packet=E2=80=99 Well I think my problem is that I don't really have a use case for this myself. So I need to understand your use case better in order to have an opinion on how best to implement it so that: 1. We can accommodate what you are trying to do and 2. We can also accommodate other related use cases, and we don't set policy in the kernel. In particular, requirement 2 is why I'm pushing back against hard-coding a mask anywhere... So could you maybe post your current ruleset and explain what it is you are trying to achieve at a high level, and why? :) Also, you keep mentioning "must be lighter on CPU". Do you have any performance numbers to show the impact of your current ruleset? Would be easier to assess any performance impact if we have some baseline numbers to compare against... -Toke