From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 58B863B2A4 for ; Mon, 18 Jun 2018 15:44:14 -0400 (EDT) Received: by mail-qt0-x22a.google.com with SMTP id s9-v6so16279235qtg.2 for ; Mon, 18 Jun 2018 12:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+Z7V7X3vgLZp7CLHbnqoKgrXJYfrt9ln2F+cW9u9/gc=; b=TOJUfRJpm8E4k5IjA/+CP68T8Ocwr3+h4Zvpkt/2tS0Bt2YYUuGCRsPF5sjowtl80c K3ViMxLV3D/3ShGYFJrqQyYnPs6Di7NUdFky23dkZzTzP/5z3abfSLZ1WiRzcEjzDOsV 22Zi40ClCIf1YpAgC4l2EGeMSbusicLdv/P3TvjPfGs/1c74MvuucU3sFxRYiXUGTx1w 48PZzjpTXP8nryXyJOwNBb/igslZWA3zf44rzDjLRmwB8/L6V2sFbZ7MWXmE5NUVfJQk vx1Op+4jfiVr8jOvqMRseQQj0Pqqqq/m4TAoJ/KcNmGJjsBDgBJeq0jybWJ1AuFbQxLG Ejtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=+Z7V7X3vgLZp7CLHbnqoKgrXJYfrt9ln2F+cW9u9/gc=; b=e3r6ikyo+7p83K7TJl0ibVMDIIfj0yQoR/k1uo7Vgo/RIjosZtiqORpCkXkog5Ddfh c0BCRAE+nUB/F2UT8CHb7Q854Ja8DgYiKbeGqBB6CA4fPEGBrs0QUrWsTNQg4EKWF8lU ow52tY5TBn6OeKcb5lPJXPre2+T+5S+hCM1I01CFzdswlCkFigJlVuz5/z/RmnHT04VZ 4TCUNDcHavzxeXT8Ha4eQ2ae22fKl3SNAVTGP1T88NlwDlAysz9r+7L3k4OFPIk329rC R8RZNL3CjPbtUIkIamCCftOdB6GU7yqcjJJye9BWAlQGFbgrAmqM7MTSJj82GKZi+NQA C2sA== X-Gm-Message-State: APt69E3f5PhpEGvNQK0HTK3cxU2ucylFOTpR8Sd9gaoZsbFbMD9eBAwT 1V+dKu4qN0pOrqq8PSEmPGMI0NdIZKqshhwTuN8= X-Google-Smtp-Source: ADUXVKL41z4FDhtmEe9eQ2CB/GwwVJ0Vw45T5hE5fZ7HlhFoXk/SSiUfVDM53wm39Q7Cz4QcAFTy4vRH3+0yO8oJF94= X-Received: by 2002:aed:2311:: with SMTP id h17-v6mr12286964qtc.144.1529351053911; Mon, 18 Jun 2018 12:44:13 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:24f0:0:0:0:0:0 with HTTP; Mon, 18 Jun 2018 12:44:13 -0700 (PDT) In-Reply-To: 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> From: Dave Taht Date: Mon, 18 Jun 2018 12:44:13 -0700 Message-ID: To: Pete Heist Cc: Make-Wifi-fast Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 19:44:14 -0000 On Mon, Jun 18, 2018 at 12:33 PM, Pete Heist wrote: > > On Jun 18, 2018, at 6:08 PM, Eric Dumazet wrote: > > > nfq_set_mode(qh, NFQNL_COPY_PACKET, 0xffff) > > -> > > nfq_set_mode(qh, NFQNL_COPY_PACKET, 128); // assuming you want to inspect > headers > > > Thanks for that. I see flat RTTs, and a sometimes significant increase in > throughputs. Unexpectedly, nfq with GSO throughputs are higher than witho= ut > nfq at all. > > ping mean (min-max) RTTs: > > APU2, nfq without GSO: 80 us -> 82 us > APU2, nfq with GSO: 85 us -> 83 us > 2011 MBP, nfq without GSO: 13 us -> 14 us > 2011 MBP, nfq with GSO: 14 us -> 13 us > > iperf3 throughputs: > > APU2, nfq without GSO: 391 -> 415 Mbps > APU2, nfq with GSO: 3.35 -> 6.07 Gbps [higher than no nfqueue, 5.55 -> 6.= 07] > 2011 MBP, nfq without GSO: 1.48 Gbps -> 2.73 Gbps > 2011 MBP, nfq with GSO: 38.0 Gbps -> 45.5 Gbps [higher than no nfqueue, 3= 9.2 > -> 45.5] This is still without batch releases, yes? In any case, the now achieved rates and latencies seem sufficient to try and adapt these methods to emulating wifi/lte etc better! We only need to get to a gbit. Obviously doing more expensive userspace processing is going to hurt, and, well, for the sake of argument emulating a 32 station wifi 802.11n network would be proof of the pudding, but I'd settle for even the simplest case of one ap and two stations actually rendering sane-looking behavior. Originally, when thinking about this, I'd thought we'd use one veth per station and toss packets to userspace based on one nfqueue per input/output interface. I still lean that way (do we get multicast mac addrs on packets this way?), but perhaps a single interface could be used and we could sort out the src/dst ips and batching in userspace, starting with fifos to represent current behavior and gradually working our way back up to the fq_codel on wifi emulation. Or, with one veth per station, still use a fq_codel qdisc, but I don't see how we can create backpressure for that actually to engage. Better to be reordering the verdict on packets in the batch for an fq_codel emulation. I think. > > > > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast --=20 Dave T=C3=A4ht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619