Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp6832186imb; Sat, 9 Mar 2019 07:31:55 -0800 (PST) X-Google-Smtp-Source: APXvYqzY4K7qH/F7n6C9+0QbYSP81uyxDegHlfWYm9rRBMc1W39q5bmr60ggv3U0P6DA10IUOsOm X-Received: by 2002:aa7:9211:: with SMTP id 17mr24062436pfo.220.1552145515572; Sat, 09 Mar 2019 07:31:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1552145515; cv=none; d=google.com; s=arc-20160816; b=B4wdhZ3OTk963802RnXK/iRqDh7nGCMCzuJ+sgLQVxD0DclnLmVmWxtt8sSGw4dXKo 4JP7DHiffvcY5ja41pYVr0bGbKGqAKDXH03npNGtgS7p9T0aK5tOZbXKECizcY/+tje8 z6OvdMpp0c0GkyH0QEGoNoWo6UlFQbPEW5NQ2jPOGeOVnaprnI/6OURXKYsFwYHYgFNB nzNFA6n94BuukALM6kS70YStAAryQx3Nw5h1h32rqSwXFLBV2rRMr2aUh8F/urMxuzPc /kUJx4WyiP8Rnv06E8m8KUsTe+VVVaiu9Pz6n3Sx2ovooRU3FynqZl917phZxczK4B9a /d+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=nRMpYaf5E2vtnJjJUJu5i61gfiOYfU/mJd/ZXoAGej8=; b=UUB7VyeL//nRGsnct+k9DbuWdPwMO+viK2ffcTKQwK+2Zm/YcGq+2WQZClbPdhxbcU DAKGYD7VHcds2UqomTHpgl4HAsyFStdvfhPk6jK50DETPJ0U24S99hQ39QS8mJuWnPVy 9WxWfHSvqgIYrg7UofFs/ovcItxcN3v/IFs4Mf4KqGVkl5P3cTUu9v63GZRpA4yEvyhQ tM2r0V4k+QPMv94dVovJ2wvYJ8MbhNT3MB56CFsxwCg9hUD/o0uZQ54G9Xd8a7JheStJ ZSoAyhGngMrNLEY4cZ4S962pLJpT1cPGcWuTTsExhkbcEj9oGnJS0xYSGrQNH1g2+KpU Imjw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=l5wkoyH2; spf=temperror (google.com: error in processing during lookup of linux-kernel-owner@vger.kernel.org: DNS error) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o188si559757pfb.66.2019.03.09.07.31.26; Sat, 09 Mar 2019 07:31:55 -0800 (PST) Received-SPF: temperror (google.com: error in processing during lookup of linux-kernel-owner@vger.kernel.org: DNS error) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=l5wkoyH2; spf=temperror (google.com: error in processing during lookup of linux-kernel-owner@vger.kernel.org: DNS error) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726359AbfCIO4d (ORCPT + 99 others); Sat, 9 Mar 2019 09:56:33 -0500 Received: from mail-wm1-f66.google.com ([209.85.128.66]:50176 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725841AbfCIO4c (ORCPT ); Sat, 9 Mar 2019 09:56:32 -0500 Received: by mail-wm1-f66.google.com with SMTP id x7so413397wmj.0; Sat, 09 Mar 2019 06:56:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=nRMpYaf5E2vtnJjJUJu5i61gfiOYfU/mJd/ZXoAGej8=; b=l5wkoyH2qtbtEO0kpFzLAs9geu7ZZ3xoakc7L4G0NJgf+R4k2SntCOz1tXJIw0M33+ WOv/1c72FAXjQqf4FECJRgAfUcbrfAFQM8q2USvrAzoHzp9uBSUGMnNqbGIzaOXQNnk2 exTZkYo7GOQh9vCr5Y8UzaRbIux6AjxqaFdpNaTsd2ewlzOW+azj72C88Mj1px++kqVu Apb38bGTx0fHjbSYygOerES1StMK9yV7iVD2ti7P5aOXuYN0YrJWetwVnq9CjMPrHxUr foIq4AST/wSZgX85YjIxswnxnNd0VDSphmHazH3grpq8Fj3nK+cX4VC/Qrqzmyo/tE3t S4rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=nRMpYaf5E2vtnJjJUJu5i61gfiOYfU/mJd/ZXoAGej8=; b=tiolnXSdPeL8EGG2zoXEzvtjYve0mNjvAShnQTODSF6JwHJp4fNAgYbPHZbHVtTCij +TNtaKsn/ReaKsR1nYCsfhBQcj89E6IlSNQ3iOVgdLees/HIUOjiqbKhZIVkdiQWttSW vDj2qQIsQ74tXlps9NoglatOmvQ5cI8tts8eQFjiVSzkkUVFd6ljmZxNe5HbKU0LriDl +4HMD2Kpw72b14pFlqDwkeEq8m/7zoRahFaM7nyxjUwd/PoTHCYFEgrGGMe4WMkHQXAZ ukUdmfg86jHBcyPXrePGMniZ+mNgOoT92PIIqIvAANwtAkTLF8nHnkJaJSIECaMsKfGG 81lg== X-Gm-Message-State: APjAAAVWAFsoTg3eTl2MBggJv2zukDqw5Qr+0Q2wX1oZxsu9o3vny49g 99r1Rw/0cgESW/mgFgZxaSkAP0gDyaU= X-Received: by 2002:a1c:4006:: with SMTP id n6mr12774808wma.137.1552143390223; Sat, 09 Mar 2019 06:56:30 -0800 (PST) Received: from ?IPv6:2003:ee:f27:ae00:bc3a:186e:8458:23ed? (p200300EE0F27AE00BC3A186E845823ED.dip0.t-ipconnect.de. [2003:ee:f27:ae00:bc3a:186e:8458:23ed]) by smtp.googlemail.com with ESMTPSA id v20sm16575854wmj.2.2019.03.09.06.56.29 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Sat, 09 Mar 2019 06:56:29 -0800 (PST) Subject: Re: [PATCH] net: can: Increase tx queue length To: Appana Durga Kedareswara Rao , "wg@grandegger.com" , "mkl@pengutronix.de" , "davem@davemloft.net" , Oliver Hartkopp Cc: "linux-can@vger.kernel.org" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" References: <1552140446-31535-1-git-send-email-appana.durga.rao@xilinx.com> From: Andre Naujoks Message-ID: Date: Sat, 9 Mar 2019 15:56:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/9/19 3:40 PM, Appana Durga Kedareswara Rao wrote: > Hi Andre, > > >> >> On 3/9/19 3:07 PM, Appana Durga Kedareswara rao wrote: >>> While stress testing the CAN interface on xilinx axi can in loopback >>> mode getting message "write: no buffer space available" >>> Increasing device tx queue length resolved the above mentioned issue. >> >> No need to patch the kernel: >> >> $ ip link set txqueuelen 500 >> >> does the same thing. > > Thanks for the review... > Agree but it is not an out of box solution right?? > Do you have any idea for socket can devices why the tx queue length is 10 whereas > for other network devices (ex: ethernet) it is 1000 ?? I think the 1000 queue length is the system default and CAN just overwrites that (a vcan does curiously does not). There probably is a reason for the short queue for CAN. But I don't know why it was set so low. My guess is as good as yours. I ran into your problem multiple times, too, when replaying recorded CAN traces. We worked around it, by adding the txqueuelen to the setup parameters for the CAN devices. If you use ifupdown (we use a different solution), then you could probably put it in there somewhere. I'd be reluctant to change that default without knowing why it was set in the first place. Maybe Oliver can help here? Regards Andre > > Regards, > Kedar. >> >>> >>> Signed-off-by: Appana Durga Kedareswara rao >>> >>> --- >>> --> Network devices default tx_queue_len is 1000 but for socket >>> can device it is 10 any reason for it?? >>> >>> drivers/net/can/dev.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c index >>> c05e4d5..32bd5be 100644 >>> --- a/drivers/net/can/dev.c >>> +++ b/drivers/net/can/dev.c >>> @@ -642,7 +642,7 @@ static void can_setup(struct net_device *dev) >>> dev->mtu = CAN_MTU; >>> dev->hard_header_len = 0; >>> dev->addr_len = 0; >>> - dev->tx_queue_len = 10; >>> + dev->tx_queue_len = 500; >>> >>> /* New-style flags. */ >>> dev->flags = IFF_NOARP; >>> >