From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <davem@davemloft.net>
Received: from shards.monkeyblade.net (unknown
	[IPv6:2001:4f8:3:36:211:85ff:fe63:a549])
	by huchra.bufferbloat.net (Postfix) with ESMTP id 24B262005CC
	for <codel@lists.bufferbloat.net>; Fri, 29 Jun 2012 00:53:58 -0700 (PDT)
Received: from localhost (74-93-104-98-Washington.hfc.comcastbusiness.net
	[74.93.104.98])
	by shards.monkeyblade.net (Postfix) with ESMTPSA id 3726B584C75;
	Fri, 29 Jun 2012 00:53:58 -0700 (PDT)
Date: Fri, 29 Jun 2012 00:53:57 -0700 (PDT)
Message-Id: <20120629.005357.1447732177584445832.davem@davemloft.net>
To: eric.dumazet@gmail.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1340949008.29822.73.camel@edumazet-glaptop>
References: <1340947448.29822.41.camel@edumazet-glaptop>
	<20120628.222934.767995619021650710.davem@davemloft.net>
	<1340949008.29822.73.camel@edumazet-glaptop>
X-Mailer: Mew version 6.5 on Emacs 24.0.97 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: nanditad@google.com, netdev@vger.kernel.org, codel@lists.bufferbloat.net,
	ycheng@google.com, ncardwell@google.com, mattmathis@google.com
Subject: Re: [Codel] [PATCH net-next] fq_codel: report congestion
 notification at enqueue time
X-BeenThere: codel@lists.bufferbloat.net
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: CoDel AQM discussions <codel.lists.bufferbloat.net>
List-Unsubscribe: <https://lists.bufferbloat.net/options/codel>,
	<mailto:codel-request@lists.bufferbloat.net?subject=unsubscribe>
List-Archive: <https://lists.bufferbloat.net/pipermail/codel>
List-Post: <mailto:codel@lists.bufferbloat.net>
List-Help: <mailto:codel-request@lists.bufferbloat.net?subject=help>
List-Subscribe: <https://lists.bufferbloat.net/listinfo/codel>,
	<mailto:codel-request@lists.bufferbloat.net?subject=subscribe>
X-List-Received-Date: Fri, 29 Jun 2012 07:53:58 -0000

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 29 Jun 2012 07:50:08 +0200

> Hmm, problem is the sender thinks the packet was queued for
> transmission.
> 
>         ret = macvlan_queue_xmit(skb, dev);
>         if (likely(ret == NET_XMIT_SUCCESS || ret == NET_XMIT_CN)) {
>                 struct macvlan_pcpu_stats *pcpu_stats;
> 
>                 pcpu_stats = this_cpu_ptr(vlan->pcpu_stats);
>                 u64_stats_update_begin(&pcpu_stats->syncp);
>                 pcpu_stats->tx_packets++;
>                 pcpu_stats->tx_bytes += len;
>                 u64_stats_update_end(&pcpu_stats->syncp);
>         } else {
>                 this_cpu_inc(vlan->pcpu_stats->tx_dropped);
>         }
> 
> NET_XMIT_CN has a lazy semantic it seems.
> 
> I will just dont rely on it.

I think we cannot just ignore this issue.  I will take a deeper look,
because we should have NET_XMIT_CN be very well defined and adjust any
mis-use.