From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 041643CB35 for ; Wed, 22 Aug 2018 05:52:02 -0400 (EDT) Received: by mail-wr1-x42e.google.com with SMTP id v16-v6so1077476wro.11 for ; Wed, 22 Aug 2018 02:52:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heistp.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7XZukpXC3oIBjgsHgeOFVkoaRo8T2NabPg8P2zJ8tkY=; b=TvbLv7HBV139e6Ysk4HPu2R9epGzNangIwPWjPZOxC27cycqz4tYJk+qkPP/OF8Yis rSTh2dgFNZ8mNu/NrXynyh5mXyrQktz5ehXBXRN9SPHp3DJFVq6lORM6UrhnRzo6n3Bn KkTnJV88Dm5Yy7VNqsdkKP1GmSLJKJ5l2kG4pIahfSNgOMf7XT42wfjgTqzlWnz5evse YbYNuR7vRkSIl5IPjqwOUhj/856iCvQfCN3twpBqq7KPaBWYJNKBuOVHozIpoSPeBVFP I0oteV/vr1+xTs8EbhYhvkzVMjHsnhZjw4Nv/IoHUgcSSxxrTqp4m5JwO9PrbBd6BcRv aDfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=7XZukpXC3oIBjgsHgeOFVkoaRo8T2NabPg8P2zJ8tkY=; b=GRQUz9P10HsV9R5Tlwf+OTghT4vHVRy3g1ydyhS0rbr5Nxdh6uvWgMpcqG9vUyvntj elYxByw43eAN3bmiZGwJuoowdHMsdhV/nDhyrw1TgyxjsXtQ2auza+8ovrYpqjQ7XgWY APy9pVgmAoBpfpdELmPOyrP4FwmVxq3Vv/mv34fm6+z7y4aWGaMFhph3pv93V57Uglg3 5SzxF47mZ1T0VjzcDb4mEEDhCr7053RGA3Il6JUTTF+BpERo0gPUf903u9KbkZdDHWll H2jpB900+W041Oo8uFtysiHq71Umjvnlzem4h8zzdeCWn7APYOLyq/xQH8G3D047XJLt +7PQ== X-Gm-Message-State: APzg51DV6DnSmTTMOTnrnJNkIcS643h9alW81p6xb07uUrsDVg213eZu BT8Fjvs2XIFttxt9RRv4A7zHOg== X-Google-Smtp-Source: ANB0VdZkq5AcFLjZ9bUyWnx1tBtolZIQ8rEc9xkqZMKug/sdCTkCubUJd/Q705ZpkkxrvhYFOsqelA== X-Received: by 2002:adf:d20a:: with SMTP id g10-v6mr818076wri.66.1534931522137; Wed, 22 Aug 2018 02:52:02 -0700 (PDT) Received: from tron.lt2.drhleny.cz ([185.15.109.151]) by smtp.gmail.com with ESMTPSA id o33-v6sm1765649wrf.11.2018.08.22.02.52.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Aug 2018 02:52:01 -0700 (PDT) From: Pete Heist Message-Id: <70F2DBF2-5B11-43AC-82FD-899A2B0931EC@heistp.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_20D3B79A-01B5-42C3-85E3-A58CF1E97770" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 22 Aug 2018 11:51:59 +0200 In-Reply-To: <87tvnm91yy.fsf@toke.dk> Cc: Jonathan Morton , Cake List To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= References: <87h8jze5hk.fsf@toke.dk> <85C60B2F-78D0-4AEE-871C-BB637785BF62@gmail.com> <4D28C453-5378-4A5B-9E05-874F36C4DB30@gmail.com> <878t5aedj5.fsf@toke.dk> <87d0uc9d2f.fsf@toke.dk> <03B32CF6-2926-42A7-A407-CBD16BA38F0D@heistp.net> <87tvnm91yy.fsf@toke.dk> X-Mailer: Apple Mail (2.3445.9.1) Subject: Re: [Cake] issue with Cake and bpf filter 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: Wed, 22 Aug 2018 09:52:03 -0000 --Apple-Mail=_20D3B79A-01B5-42C3-85E3-A58CF1E97770 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 22, 2018, at 11:37 AM, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >=20 > Pete Heist writes: >=20 >>> On Aug 22, 2018, at 8:17 AM, Jonathan Morton = wrote: >>>=20 >>> One difference between fq_codel and Cake is that the former - which >>> has no shaper - will "bypass" packets when it's empty and there's no >>> back-pressure filling it. In that case no packet classification >>> occurs and filters will not be called. Or at least, that's how it >>> used to be set up; I haven't looked at it recently. Cake does not >>> rely on the same set of assumptions, so will always call the filter. >>=20 >> Aha, that sounds likely, I=E2=80=99ll try with htb and a rate limit. = Testing >> with fq_codel was challenging as I had to =E2=80=9Cdo stuff=E2=80=9D = until my printk=E2=80=99s >> were eventually called, but it=E2=80=99s easier now that I can use = cake. I >> suppose in my case fq_codel=E2=80=99s behavior would be ok in = production, >> because if there=E2=80=99s no queue then there=E2=80=99s no need to = classify. Maybe in >> some other cases (like gathering stats), it could be problematic. >=20 > fq_codel turns off the bypass capability if you attach a tc filter to > it, though, so if the issue you're seeing is that you filter function = is > not being called, that sounds... strange... >=20 > How do you check if the function is being called? With printk and "sudo tc exec bpf dbg=E2=80=9D to tail the output. For = example, in act_main of this file I just added one more line to print = =E2=80=9Cact_main=E2=80=9D if TCU_DEBUG is defined: https://github.com/heistp/tc-users/blob/master/tc-users-bpf.c = And here=E2=80=99s an example of verifier weirdness (not that you need = to look into this)=E2=80=A6 If IPV6_SUPPORT_V2 is defined but TCU_DEBUG is not, the verifier error = is: "math between pkt pointer and 4294901760 is not allowed" If IPV6_SUPPORT_V2 is defined but TCU_DEBUG *is* (which just defines the = prink func and adds two printk lines, and otherwise works without = IPV6_SUPPORT_V2 defined), the verifier error is: "R3 bitwise operator &=3D on pointer prohibited"= --Apple-Mail=_20D3B79A-01B5-42C3-85E3-A58CF1E97770 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Aug 22, 2018, at 11:37 AM, Toke H=C3=B8iland-J=C3=B8rgensen = <toke@toke.dk> = wrote:

Pete Heist <pete@heistp.net> writes:

On Aug 22, 2018, at 8:17 AM, Jonathan Morton <chromatix99@gmail.com> wrote:

One difference between fq_codel and Cake is that the former - = which
has no shaper - will "bypass" packets when it's = empty and there's no
back-pressure filling it. In that = case no packet classification
occurs and filters will not = be called. Or at least, that's how it
used to be set up; I = haven't looked at it recently. Cake does not
rely on the = same set of assumptions, so will always call the filter.

Aha, that sounds likely, I=E2=80=99= ll try with htb and a rate limit. Testing
with fq_codel = was challenging as I had to =E2=80=9Cdo stuff=E2=80=9D until my = printk=E2=80=99s
were eventually called, but it=E2=80=99s = easier now that I can use cake. I
suppose in my case = fq_codel=E2=80=99s behavior would be ok in production,
because if there=E2=80=99s no queue then there=E2=80=99s no = need to classify. Maybe in
some other cases (like = gathering stats), it could be problematic.

fq_codel turns off the bypass capability if you attach a tc = filter to
it, though, so if the issue you're seeing is = that you filter function is
not being called, that = sounds... strange...

How do you check if = the function is being called?

With printk and "sudo tc exec bpf dbg=E2=80=9D to tail the = output. For example, in act_main of this file I just added one more line = to print =E2=80=9Cact_main=E2=80=9D if TCU_DEBUG is defined:

https://github.com/heistp/tc-users/blob/master/tc-users-bpf.c

And = here=E2=80=99s an example of verifier weirdness (not that you need to = look into this)=E2=80=A6

If IPV6_SUPPORT_V2 is defined but TCU_DEBUG is not, the = verifier error is:

"math between pkt pointer and 4294901760 is not = allowed"

If = IPV6_SUPPORT_V2 is defined but TCU_DEBUG *is* (which just defines the = prink func and adds two printk lines, and otherwise works without = IPV6_SUPPORT_V2 defined), the verifier error is:

"R3 bitwise operator &=3D on = pointer prohibited"
= --Apple-Mail=_20D3B79A-01B5-42C3-85E3-A58CF1E97770--