From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (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 4EBC03B2A4 for ; Mon, 18 Jun 2018 18:27:19 -0400 (EDT) Received: by mail-pf0-x243.google.com with SMTP id c22-v6so8884803pfi.2 for ; Mon, 18 Jun 2018 15:27:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=QXE/j1oKfrQ+f/jtwQPoij8koMFtA4C/78tNmcRzgQc=; b=dDHdUkm7yt0wc2JfUWtPZcE+g6vliQ2yXVJsHIT4b9AZQH3NwR1NtDM0GIsK6leEBd H8eUzX4JU7RfA57qr9bd+U+zvWnh9xbXHLi1M5Urr40s4yYNU9E77fF7HvJVsYU7iCVS Q4Ks5HRoOoKkm2FVI89PF2xI0FaKqAA248GMBaS4Y/wPNpDQMDJoxLtfq1540nOG0j5c 3rGoy1tIlwhKnT1KBppz+OrH4WyMNc2PtzEAVT4u0pd5IV3XKTT9i0XfWtTQ2OX/K5Ws A2dSpmRuUVfCbLpY86sONWLqLbJLN892JmgSz8QX8D9nriummn43dYbBbc2Vw2xv1hxp Qihg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=QXE/j1oKfrQ+f/jtwQPoij8koMFtA4C/78tNmcRzgQc=; b=YNBG2bu+lAzz15yV1jjiMhtWCkJ1WV3S0OmqpYKmutRvp28neu593X2DtXpQ7GypLt H8SBVgEjyFsirDdiC4PmqVgMTMXIK74OIMrAWBALGjM0wBCDEb8wSij4RVwWOP2Wa4VI bz7kLd3lNVR5VsSWgt4ht3Fto8LYIBO0EalAOUweXIRX4L64DT+Y78pShT2jt+UPo5aK ELlUT+o7ppLicygxrIRHV1AEUhrfH9KJtK3rKZshLZLLZLiJ4zMIqn5AOBw2oC8czOSs I31H8pgg0N+MDYB3sK5u8r9ycHVgHiaIyuhZtGTp5/FD2hRilWIL2OdZnM/gEbi0+de4 qc0Q== X-Gm-Message-State: APt69E3h84ugzCOxdlAdwyVwl+DQg3f1ESdrUZ98npg8E9dUKkV0lMJw GTmfco16ceawWu1j6RXBRvcb2yZl X-Google-Smtp-Source: ADUXVKL2H/mHM1Z+Oap0S4sN4iOhle0iH8nJRKlWVXCrkQr+PLIpt/6tnOvi6G0dBfLZ+vP+C3rOjA== X-Received: by 2002:a65:5b8b:: with SMTP id i11-v6mr12538148pgr.225.1529360838368; Mon, 18 Jun 2018 15:27:18 -0700 (PDT) Received: from ?IPv6:2620:15c:2c1:200:55c7:81e6:c7d8:94b? ([2620:15c:2c1:200:55c7:81e6:c7d8:94b]) by smtp.gmail.com with ESMTPSA id q10-v6sm25476398pfj.7.2018.06.18.15.27.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Jun 2018 15:27:17 -0700 (PDT) To: make-wifi-fast@lists.bufferbloat.net References: <1527721073.171416827@apps.rackspace.com> <150ABF21-FAFC-48E2-9E55-CAA609EAE449@heistp.net> <20180617131921.09bf5353@redhat.com> <5CC11C44-6C78-410D-B699-B4B1A6F5FBDD@heistp.net> <8f5915f8-7dad-f881-b0c8-f6b03165c675@gmail.com> <96697B23-46AB-4BA7-8B7E-2A66C1E67911@heistp.net> From: Eric Dumazet Message-ID: Date: Mon, 18 Jun 2018 15:27:14 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <96697B23-46AB-4BA7-8B7E-2A66C1E67911@heistp.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [Make-wifi-fast] emulating wifi better - coupling qdiscs in netem? X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 22:27:19 -0000 On 06/18/2018 02:54 PM, Pete Heist wrote: > >> On Jun 18, 2018, at 9:44 PM, Dave Taht > wrote: >> >> This is still without batch releases, yes? > > Yes, I should've tried that earlier, but I’m scratching my head now as to how it works. Perhaps it’s because the old example I’m using for the non-GSO case uses deprecated functions and I ought to just ditch it, but I thought if in my callback I just switched: > > return nfq_set_verdict(qh, id, NF_ACCEPT, 0, NULL); > > to > > return nfq_set_verdict_batch(qh, id + 8, NF_ACCEPT); > > that my callback might not be called for the subsequent 8 packets I’ve accepted, however it continues to be called for each id sequentially anyway and throughput is no better. If I change 8 to something unreasonable, like 1000000, throughput is cut in half, so it’s doing “something”. > > There are functions in the newer GSO example like nfq_nlmsg_verdict_put, but I don’t see a batch version of that. So, I’m likely missing something… > > BTW I don’t see a change setting SO_BUSY_POLL on nfq’s fd (tried 1000 - 1000000 usec). > busy polling does not request SO_BUSY_POLL. Usually, we simply use non blocking system calls in a big loop. ( nl_socket_get_fd() -> then set the file in O_NDELAY mode) SO_BUSY_POLL is a way to directly call the NAPI handler of the device (or more precisely RX queue) feeding packets. This saves the hard interrupt latency. For NFQUEUE, that would require a bit of plumbing I guess. Each NF Queue would have to record (in the kernel) the NAPI id of intercepted packets. -> A bit complicated since the number of RX queues on a NIC/host is quite variable.