From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 187FEFA3728 for ; Wed, 16 Oct 2019 23:22:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D733720872 for ; Wed, 16 Oct 2019 23:22:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=netronome-com.20150623.gappssmtp.com header.i=@netronome-com.20150623.gappssmtp.com header.b="jQksH76h" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2403853AbfJPXW3 (ORCPT ); Wed, 16 Oct 2019 19:22:29 -0400 Received: from mail-lf1-f65.google.com ([209.85.167.65]:37859 "EHLO mail-lf1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725970AbfJPXW2 (ORCPT ); Wed, 16 Oct 2019 19:22:28 -0400 Received: by mail-lf1-f65.google.com with SMTP id w67so298420lff.4 for ; Wed, 16 Oct 2019 16:22:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=mjecSzPejQYaalbPR09N+D4rzebtX70neEvOMFMrPjM=; b=jQksH76hXXm+CjdyTzPWlxYkfjjcm1FqNADVzNNjVfXkulWBWVE5Tlge0+lpoYpR8U ms9M/oa/3V8cf9tbEu4Eo1s9GQm4/xrDE5IwXpRF7j6wnovrOV3EfgMsupss2fW5Hi1s JMzGvNH7GSHmGzaiWG/eX/lIHTJJPLVoNMid7gBjSmBhSUO77PPIFw6SGnaZL4BLsnJe kxGZ8eqOWrvNVWKATZnnjjDf7ueWUV8eLmuw/iHrXz2qlahkTjpH5AT5ol0TK/f1HB0/ JztA6Il0Mq/oqgIxDyJIz9OV6EErabQOoZ/3wWQVHwZ7gEUepOQocvafVpQWgWkAAJef WhTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:organization:mime-version:content-transfer-encoding; bh=mjecSzPejQYaalbPR09N+D4rzebtX70neEvOMFMrPjM=; b=as1r1TPrn4a+qldfU+CTcRbZtpfCId6lEo/50MAFvJwvNs5tZTalKs/V+wornIdGkZ kg307bGjD/20251CZZLx3c1t/yDrI4o7c3P7sNsSquGd6+Ve18sGG8sFWQBVJqWKoiME avq8sStczH4M5tal7Je3T9FkduOr1pCgmkuoHJq5nwcU5E5dQxDPe6GeLBMYNeb1Qaw4 b6nXRoU7MpUwksEV3jbEhoIesBuGs3W61fG+bINIMIIP3vnzfIE+Ntel3l5dzlsczG7r nGJQl4mBf5f5978EDuFplVRNApfAVHUVqIwrtiuNTGAXby7eRPh+rmyEit7M2LW6FO/6 PInA== X-Gm-Message-State: APjAAAVmCdLD9AzmV24aKkqZOCruRyXgyOTKC8bEO0+uBD9yeR1H+42v pSk/6LaWUuOqbn47j20idOljHg== X-Google-Smtp-Source: APXvYqzEay8w7Zvc16jpgSqkLos3NGdxinFDjPoFQ4x9UCUutdBvEzYkh0FltsERvk16ZD7HHckNDA== X-Received: by 2002:a19:f013:: with SMTP id p19mr169048lfc.98.1571268146533; Wed, 16 Oct 2019 16:22:26 -0700 (PDT) Received: from cakuba.netronome.com ([66.60.152.14]) by smtp.gmail.com with ESMTPSA id q5sm90434lfm.93.2019.10.16.16.22.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Oct 2019 16:22:25 -0700 (PDT) Date: Wed, 16 Oct 2019 16:22:18 -0700 From: Jakub Kicinski To: Cong Wang Cc: David Miller , Linux Kernel Network Developers , oss-drivers@netronome.com, Stephen Hemminger , kbuild test robot , Dan Carpenter , Ben Hutchings , Simon Horman Subject: Re: [PATCH net] net: netem: fix error path for corrupted GSO frames Message-ID: <20191016162210.5f2a8256@cakuba.netronome.com> In-Reply-To: References: <20191016160050.27703-1-jakub.kicinski@netronome.com> Organization: Netronome Systems, Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, 16 Oct 2019 15:42:28 -0700, Cong Wang wrote: > > @@ -612,7 +613,7 @@ static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch, > > } > > segs = skb2; > > } > > - qdisc_tree_reduce_backlog(sch, -nb, prev_len - len); > > + qdisc_tree_reduce_backlog(sch, !skb - nb, prev_len - len); > > Am I the only one has trouble to understand the expression > "!skb - nb"? The backward logic of qdisc_tree_reduce_backlog() always gives me a pause :S Is -nb + !skb any better? The point is we have a "credit" for the "head" skb we dropped. If we didn't manage to queue any of the segs then the expression becomes ...reduce_backlog(sch, 1, prev_len) basically cleaning up after the head. My knee jerk reaction was -> we should return DROP if head got dropped, but that just makes things more nasty because we requeue the segs directly into netem so if we say DROP we have to special case all the segs which succeeded, that gets even more hairy. I'm open to suggestions.. :(