From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 84F3EA0547; Tue, 26 Oct 2021 16:38:25 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 608FA4111C; Tue, 26 Oct 2021 16:38:25 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mails.dpdk.org (Postfix) with ESMTP id 9785E407FF for ; Tue, 26 Oct 2021 16:38:22 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10149"; a="229784379" X-IronPort-AV: E=Sophos;i="5.87,184,1631602800"; d="scan'208";a="229784379" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Oct 2021 07:30:11 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.87,184,1631602800"; d="scan'208";a="446773727" Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by orsmga006.jf.intel.com with ESMTP; 26 Oct 2021 07:30:10 -0700 Received: from fmsmsx612.amr.corp.intel.com (10.18.126.92) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Tue, 26 Oct 2021 07:30:10 -0700 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx612.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Tue, 26 Oct 2021 07:30:10 -0700 Received: from FMSEDG603.ED.cps.intel.com (10.1.192.133) by fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12 via Frontend Transport; Tue, 26 Oct 2021 07:30:10 -0700 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (104.47.57.47) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.12; Tue, 26 Oct 2021 07:30:10 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ERe079loIJ/sOW6WJhLr+ZZjKvgtypGtqnCHLqX0nIEe/tlUP+TnYffrODyHfvU3kyWOxbSv8xnKY3B33nHScw6ldkpTW0/GqzBi7MjuVm/eV2lcvQ4J+bQaUcK5nMBX3/aVbv04D6JeLewruh6TJsaD1t3h3ak9Rlr6us2pgqpAb/7vULwVjohJZK7lLmIfH3iEJ7rChHC3dnPS+w/Ub6J2y6d0Qy6OMfTz7kvc3Msp4QHTSNXWRznbytMQ6mkfRNS39VV0Djc6NHhR3xoCNVzfTJXDVFLq9WGJBa/VsjIRRxcoGwERzXF6cSn40BF0f3HjM5YRYJXbhUjAk7mFKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/cm7iV+pvEN4L+Wxa0UR1vEaRmQ5V/SKKXarhqtlUCE=; b=A+RElb1hDqZqToJUm9D04fFAssquPZwX4FnJ82DrE57dZACR9BiXn5wUGQ2o4mxM2hZR5S3jjNr62Rx6+Z1nIj+taZFkJpiGXrJYbjmRuoljZuJb5pjO0/3EwkJOuzoFfqxSZcLKI7SH1Mxa5Liu2mgHUCUfmyb9Mh6KsNAambWkmoChvjBsaLZnCZvOj0vDyuhfShGxggK3oj1s1RtFNDVT/Fw515mYkVwMBDL6rPf/d613zDCDVhWxCIhegiztYV7flG6Aa4TneomBy1s1D1oqmoIazpJjoosAzfM2dVU9YPJn0oCFF/K8ksVZl9VYJf4VSUv7x6RSi+OolZQ80A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/cm7iV+pvEN4L+Wxa0UR1vEaRmQ5V/SKKXarhqtlUCE=; b=D67bvBIPZJQ8soL/bw3pawaXHbXX3dfcnfE5BplWOB21BpxTVC+OFmgIGeFA8G2TzgulYW/zya63nKfce/FDCnh6Y4/KdDBycz8I7SKewCCDv14yCpA/RiCwCjBHvui6Ki2VQTLiOy/8oX3SarX6HfdkcMmLjtyJeHzOa2+Ed4k= Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=intel.com; Received: from PH0PR11MB5000.namprd11.prod.outlook.com (2603:10b6:510:41::19) by PH0PR11MB4903.namprd11.prod.outlook.com (2603:10b6:510:36::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4649.13; Tue, 26 Oct 2021 14:30:08 +0000 Received: from PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::bd7d:29be:3342:632c]) by PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::bd7d:29be:3342:632c%6]) with mapi id 15.20.4628.020; Tue, 26 Oct 2021 14:30:08 +0000 Message-ID: <7dd5cbb2-dfb8-8c54-9b48-9e271c0e51b1@intel.com> Date: Tue, 26 Oct 2021 15:30:00 +0100 Content-Language: en-US To: Tudor Cornea CC: , Thomas Monjalon , "Mihai Pogonaru" , References: <1629466761-127333-1-git-send-email-tudor.cornea@gmail.com> <1631540746-38443-1-git-send-email-tudor.cornea@gmail.com> <9ec3e2cb-412a-a48b-2567-7e5ad6b1153f@intel.com> From: Ferruh Yigit X-User: ferruhy In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: DB6PR0202CA0029.eurprd02.prod.outlook.com (2603:10a6:4:a5::15) To PH0PR11MB5000.namprd11.prod.outlook.com (2603:10b6:510:41::19) MIME-Version: 1.0 Received: from [192.168.0.206] (37.228.236.146) by DB6PR0202CA0029.eurprd02.prod.outlook.com (2603:10a6:4:a5::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.16 via Frontend Transport; Tue, 26 Oct 2021 14:30:06 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d112169d-8b75-4d6c-1ee7-08d9988d1c0d X-MS-TrafficTypeDiagnostic: PH0PR11MB4903: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 4VjxgUwuFQQsk6TvQg8wEH1NtiD85XkQpm1zixH5LLlyFIebqzFTJsHPpiRiv9ca5d4CtvWjLafetNkvTse6RceRsPwcHbewXutGbUr5JqQHVOkt+snbbGXh0UASXQRRpZTVhTx/xmmLTERFNtNmzhneHA/+kKLoNDyIBn4Ila8nUrPT523+mnXQAvAgGRGKq46+XZbo/DgrI/DmPcjtqEaT+VAb+YZGl3u8Hmb/0c1fTFyb+Z6blyvqc+o2hSwJLYK9uXCeuUl6u8YpQnlbP1M+z4RbHLP43KVwL239X8nppOgnGVLdkBSC7aT2oMpFU730qKmWn9b6xCGcpGYcXAd9PCWN0gwSBTzlt5tCoRlfI2P4XzYCqAGVbYF/FpnTHDseAvUE/BsIYu6VV8QGQ3vFKzY/d1k8Ee91BBqtZk2F6q2RM67rtVVOtXjSwYEvQHjiQwYuENkgh1bh+IKyrv7goUZL/ZDsUOC/BXVXvlg9nwGFDdbG6tgk0E49G7+KLBBCP5PuYSXYOk+Zq/9A66P6S1oEXJiKJxcIjOSrBiPX2GZEFHabidu9wL5jsBvvAEJCm3Fvr0NwQX3agmM1tAVrQFo8vxBiz0tHAvHuJWdGfWlRZuFMiA37nxUpFTxUD8y5WBbhdutizs6s11zCZtVQqtzdfYWbBxEA7xYIh5A0qT6IQGAE8EBRzzHTF/2njZg2eaVGcdkVqmKjlAt2fme4TPaZa4HumpuapC0E4m7ziWmXiSpKXxDYwRJ/9Et68d2rTh/WzTzI3V/5hn2HaGMAJ+X9YPyl5nIZtIEn7cU= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB5000.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(316002)(5660300002)(38100700002)(956004)(54906003)(4326008)(2616005)(31686004)(16576012)(6916009)(31696002)(966005)(8936002)(26005)(6486002)(2906002)(6666004)(44832011)(66556008)(186003)(66476007)(83380400001)(82960400001)(36756003)(53546011)(508600001)(66946007)(8676002)(86362001)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?YzhEQzRpMzN4TXNjaEo3cHBZUkFUbUc3eERkMngwWVdBZng5UzlWaDF6VVdO?= =?utf-8?B?eUZrYUtRUTRWdWszQ1E2UjJDZ2VCWnE2MG9IVUF1RUNYWFdRbmVnZVIvdDhI?= =?utf-8?B?dFVBRWMwTGNxVEFUWDBYUmVldVNzWHhGZHU2ais2dVZkdTR6cS9jRGhaaXlo?= =?utf-8?B?SW42NmFtSyt5NVp0QnBRems2V0tXZHljQUwyeU5oSExhZmk1emVzWE5WQUNk?= =?utf-8?B?N2xtQkFCL09XNGlQUkZ3SjdvYTA5MnphNW1OTzZuajNhbTRmVnc3a3NncUN5?= =?utf-8?B?SVRyQlVCcnhhTW5wYmVuUUZ1bEsxTHBVQTV0b2VCM1prVFJOOUJ5RmtaWi9F?= =?utf-8?B?NmhGZk9qZ1lyelQ0MFFwWEFqT29QN2hFNUlSc2hZQ2R0T000eTEyTDgzdGQz?= =?utf-8?B?MW5TcWFVbjR5Q1JJc1ZnbDExWTQxTWlKenRlVUI2UjZJeUYxaUJRNTBVRlI4?= =?utf-8?B?M0ZDY0hvSGNrQ3RDZzRvcGk2S08xWTlqejdwTWkvZWdMSW5uMkIzMWFORFV2?= =?utf-8?B?a0VRMjdQOXRad093WXc3UnVzNXRnTnVFM2RkcEpNNTNZdEN6T3pkTlFyaXZI?= =?utf-8?B?S0tOMFd6bXkxLzNCbjlHb3F6RzdRMEhsQ0pGYktUTkRoeGpuYzZRQlpNdlZX?= =?utf-8?B?NEY4cXNhUHpFaU9leldjdUJJOTRXVWE0QzE3cDBqVTNzRkx0UjdjN3FXUmtL?= =?utf-8?B?M0NJdjZPSVJ4OGE5Qk1HOFp1dllNbTB3OFdaZjVnOUpoWXMrU0pKNkdEMzE0?= =?utf-8?B?MFUxaVpyZ2ZzbGZJNHdMdG13bTBGaURHS0FMOTBYcjR6Q1JjeFlreE9SaXc3?= =?utf-8?B?QXd3ZW1aUXN5V2F4YVlTcXJEUGpKTkJnMHo0UGNQT2xTU0d3bXRQbXJ0ZVM1?= =?utf-8?B?Zkx3KzNqNVVLVTcyeVg4b0RKQS9BaWlpT292S0pKdFhadlZReXBaZVZsSjdK?= =?utf-8?B?aHk0WG8wSnpvNU4rTVorajFiRStQQllyL3hlMGlBbE5nK3hsTmEzRDViNzdw?= =?utf-8?B?a1VPdSswTzRucW9VbHVNUHN2OFN4NENrdUxCTGNuMHB0ZXFUdmNyK1d5RjBG?= =?utf-8?B?eTk0YTZJUG14aCtxdGEzMzF1MVpPZWhDOXlBL3N5aDRpTUxScElqNmdvYklW?= =?utf-8?B?Mkw4b1NFd1MwcnVuRU1uMUlyblhmd21WZCtjajAwaHBDb3dGRldoMEplbFNn?= =?utf-8?B?U1JjUFd0cUtkd2tZSFROTitsS2thdE5hRGd6cXRNSTFPMFJkR1ZQdXU0dzJo?= =?utf-8?B?bEhrVEI4N2JJL3VlWUF1R1ZSem9aZnpDZk44Q2srSXNsNk5UT0NmYmMxeWFa?= =?utf-8?B?UFFYVTlsZTBwRXVJNk5pWmJtKzVnR0ZZNjBsdkJxSGFNbzdpNUhJS2xBN3Jz?= =?utf-8?B?Rm5yd2xYcUVJNzF3dmpoR3c5SFNrOFRJNk5ocUFTZy9XWUZPWk9lU1BqWkRx?= =?utf-8?B?WEhCeG9uN1RoRkZOeGZ3WFpndlBTWVpzdjFUdThuRC9mWGZyYVlDbjBvUE55?= =?utf-8?B?cEVWWjd3RnJ5VlpUYnp1aTRGeWFnNzdVTmZ3NGIybWtjZk1UNWFEWldyckNj?= =?utf-8?B?cFFvTm5nNXA0U2dzdXM3clZ3RnBRKzljZHRYTldUMlRtUEhrTFZwNVlNZXR2?= =?utf-8?B?aHJmUDJla0V6dWtVS3lCL3J3NnBITWQ5Wk4xUVhxN3pOcllSTC8vNldvbTZl?= =?utf-8?B?MWJ1NWVWMUJKWmVIRTlVdlBjcFJpbTlFbmhWZnE5b3hUUy9VdFpielZURGl0?= =?utf-8?B?SERva2k0dlpRK3lDZnBiSTZIQ3h0eGtPc3NZT0hYbUtRVXg1ZDBURkU1dEs2?= =?utf-8?B?OUJLb1NGV3VMZzhsZVZEV1g4bHpodUdkRFE4Ym96ZUlncXR1cUYvMTVwRUFt?= =?utf-8?B?eitjU01RZjV5TktMNDJQWlRkNjJlZHhJaE1mUnRVUlJNQnVkOUZwYm00b0Iw?= =?utf-8?B?TmZCLzZPeUNuek9PbHhNWkVhZkZHTStLMk45RTNIUDZZd25FOG5DZjQvZzcr?= =?utf-8?B?QlBCcElialJRRDBVdHRKQW93dnhXQWJWUXRqSk9DK2lscmIzU2tzbkk0Z3d5?= =?utf-8?B?OG44TnZucm55cE5xSXhpWnpoVTNvbmdiaHBIRGg2b1RZa0JqdzI5Q1lNVXl0?= =?utf-8?B?dnVuTzBUN1d6eGNPRHA2SU92eVpLTlRlN3VaNnVTYXlXVVVpbmlEam9yQVZQ?= =?utf-8?Q?HDwjbh1G0CIKNcwVVjQztT4=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: d112169d-8b75-4d6c-1ee7-08d9988d1c0d X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5000.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2021 14:30:08.0876 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: SBVWdymKnns/+ZtaqJD3yFQuQ4gyWKcs9W+O+j4mFuZJPfz+FYvCl7m2alw+NgqTP54vxYWuFjVJDaw8yK7IbQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4903 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v2] net/af_packet: fix ignoring full ring on tx X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 10/5/2021 4:11 PM, Tudor Cornea wrote: > Hi Ferruh, > > I have attempted to narrow down the issue. > I have the following bash script, which computes packet rates on an > interface. > > [root@localhost ~]# cat compute-rates.sh > #!/usr/bin/env bash > > if [[ ${#} -ne 2 ]]; then > echo "Usage: ${0} " > exit 1 > fi > > IFACE_NAME="${1}" > SLEEP_INTERVAL_SECONDS="${2}" > TMP_STATS_FILE="/tmp/netstat" > > # Clear Previous stats file > echo "0 0 0 0" > "${TMP_STATS_FILE}" > > echo "Press CTRL+C to exit..." > > while true; do > export "RxB=0" "RxP=0" "TxB=0" "TxP=0" > > # Extract Rx{Bytes,Packets} and Tx{Bytes,Packets} and > # format the output. Individual fields will be exported > export $(\ > ifconfig "${IFACE_NAME}" \ > | grep 'packets' \ > | awk '{print $5, $3}' \ > | xargs echo \ > | sed -E -e \ > "s/([0-9]+) ([0-9]+) ([0-9]+) ([0-9]+)/RxB=\1 RxP=\2 > TxB=\3 TxP=\4/") > > # Print Packet and Byte Rates > # Format: | Rx Bytes | Rx Packets | Tx Bytes | Tx Packets | > > echo "${RxB}" "${RxP}" "${TxB}" "${TxP}" $(cat "${TMP_STATS_FILE}") \ > | awk '{print "RxB="$1-$5, "RxP="$2-$6, "TxB="$3-$7, "TxP="$4-$8}' > > # Save the new values > echo "${RxB}" "${RxP}" "${TxB}" "${TxP}" > "${TMP_STATS_FILE}" > > sleep "${SLEEP_INTERVAL_SECONDS}" > > done > > On the transmit side, I'm using the engine behind [1] with the af_packet > PMD. > > The configuration for the af_packet PMD is the following: > --vdev=net_af_packet0,iface=eth1,blocksz=16384,framesz=8192,framecnt=2048,qpairs=1,qdisc_bypass=0 > > I'm configuring a Tx rate of 335 packets / second and a packet size of 300 > Bytes. > These seem to be the values using which we seem to have better chances of > seeing the problem. I suspect it might also be linked with the af_packet > configuration. > > I'm starting traffic using the specified configuration, and in parallel, > running the script that computes the rates as follows: > ./compute-rates.sh eth1 0.1 > > Initially, the packet rates seem steady > > RxB=0 RxP=0 TxB=10952 TxP=37 > RxB=0 RxP=0 TxB=10656 TxP=36 > RxB=0 RxP=0 TxB=10656 TxP=36 > RxB=0 RxP=0 TxB=10656 TxP=36 > RxB=0 RxP=0 TxB=10952 TxP=37 > RxB=0 RxP=0 TxB=10952 TxP=37 > RxB=0 RxP=0 TxB=10360 TxP=35 > RxB=0 RxP=0 TxB=10952 TxP=37 > > [...] > > After a while, we toggle the interface up / down with a sleep between the > steps. I suspect the length of the sleep might be a variable in the > equation. > > ifconfig eth1 down; sleep 7; ifconfig eth1 up > > > What we see, is that even after the interface is toggled back up, the rates > never seem to recover. > > RxB=0 RxP=0 TxB=0 TxP=0 > RxB=0 RxP=0 TxB=0 TxP=0 > RxB=0 RxP=0 TxB=0 TxP=0 > RxB=0 RxP=0 TxB=0 TxP=0 > RxB=0 RxP=0 TxB=2072 TxP=7 > RxB=0 RxP=0 TxB=10360 TxP=35 > RxB=0 RxP=0 TxB=10360 TxP=35 > RxB=0 RxP=0 TxB=10360 TxP=35 > RxB=0 RxP=0 TxB=10360 TxP=35 > RxB=0 RxP=0 TxB=10360 TxP=35 > RxB=0 RxP=0 TxB=10360 TxP=35 > RxB=0 RxP=0 TxB=10360 TxP=35 > RxB=0 RxP=0 TxB=10360 TxP=35 > RxB=0 RxP=0 TxB=521256 TxP=1761 > RxB=0 RxP=0 TxB=0 TxP=0 > RxB=0 RxP=0 TxB=0 TxP=0 > RxB=0 RxP=0 TxB=0 TxP=0 > > [...] > > > I've attempted to mirror the same behavior using dpdk-pktgen [2] on a > different machine (Ubuntu 20.04). This time, af_packet runs on top of > a Linux virtio_net interface. > > I seem to be getting a similar behavior. I have used the following > dpdk-pktgen configuration and run-time settings > > > pktgen \ > -l 1-4 \ > -n 4 \ > --proc-type=primary \ > --no-pci \ > --no-telemetry \ > --no-huge \ > -m 512 \ > --vdev=net_af_packet0,iface=eth1,blocksz=16384,framesz=8192,framecnt=2048,qpairs=1,qdisc_bypass=0 > \ > -- \ > -P \ > -T \ > -m "3.0" \ > -f themes/black-yellow.theme > > set 0 size 300 > set 0 rate 0.008 > set 0 burst 1 > start 0 > > > [1] https://github.com/open-traffic-generator/ixia-c > [2] http://code.dpdk.org/pktgen-dpdk/pktgen-20.11.2/source/INSTALL.md > > On Wed, 29 Sept 2021 at 13:03, Tudor Cornea wrote: > Hi Tudor, I have used testpmd, 'txonly' forwarding. Tx recovers after interface up, but by adding some debug logs I can see 'poll()' returns with POLLOUT even there is no space in the buffer. According the logic in the PMD, when 'poll()' returns success, it expects to have some space in the Tx buffer. So I agree to add the check. Only have a question on the POLLERR, should we separate the POLLERR check to cover ifdown case, what do you think about following logic: if (!TP_STATUS_AVAILABLE) { if (poll() < 0) break; if (pfd.revents & POLLERR) break; } if (!TP_STATUS_AVAILABLE) break; >> Hi Ferruh, >> >> What you described above looks like a ring buffer with single producer and >>> single consumer, and producer overwrites the not consumed items. >> >> >> Indeed. This is also my understanding of the bug. >> I am going to try to isolate the issue, and should probably be able to >> come up with a script in a few days. >> >> Our of curiosity, are you using an modified af_packet implementation in >>> kernel >>> for above described usage? >> >> >> We are currently using an Ubuntu-based distro with a 4.15 Linux kernel. >> We don't have any kernel patches for the af_packet implementation to my >> knowledge (probably excepting patches that are back-ported by Ubuntu >> maintainers from newer releases). >> >> >> On Mon, 20 Sept 2021 at 20:44, Ferruh Yigit >> wrote: >> >>> On 9/13/2021 2:45 PM, Tudor Cornea wrote: >>>> The poll call can return POLLERR which is ignored, or it can return >>>> POLLOUT, even if there are no free frames in the mmap-ed area. >>>> >>>> We can account for both of these cases by re-checking if the next >>>> frame is empty before writing into it. >>>> >>>> Signed-off-by: Mihai Pogonaru >>>> Signed-off-by: Tudor Cornea >>>> --- >>>> drivers/net/af_packet/rte_eth_af_packet.c | 19 +++++++++++++++++++ >>>> 1 file changed, 19 insertions(+) >>>> >>>> diff --git a/drivers/net/af_packet/rte_eth_af_packet.c >>> b/drivers/net/af_packet/rte_eth_af_packet.c >>>> index b73b211..087c196 100644 >>>> --- a/drivers/net/af_packet/rte_eth_af_packet.c >>>> +++ b/drivers/net/af_packet/rte_eth_af_packet.c >>>> @@ -216,6 +216,25 @@ eth_af_packet_tx(void *queue, struct rte_mbuf >>> **bufs, uint16_t nb_pkts) >>>> (poll(&pfd, 1, -1) < 0)) >>>> break; >>>> >>>> + /* >>>> + * Poll can return POLLERR if the interface is down >>>> + * >>>> + * It will almost always return POLLOUT, even if there >>>> + * are no extra buffers available >>>> + * >>>> + * This happens, because packet_poll() calls >>> datagram_poll() >>>> + * which checks the space left in the socket buffer and, >>>> + * in the case of packet_mmap, the default socket buffer >>> length >>>> + * doesn't match the requested size for the tx_ring. >>>> + * As such, there is almost always space left in socket >>> buffer, >>>> + * which doesn't seem to be correlated to the requested >>> size >>>> + * for the tx_ring in packet_mmap. >>>> + * >>>> + * This results in poll() returning POLLOUT. >>>> + */ >>>> + if (ppd->tp_status != TP_STATUS_AVAILABLE) >>>> + break; >>>> + >>> >>> If 'POLLOUT' doesn't indicate that there is space in the buffer, what is >>> the >>> point of the 'poll()' at all? >>> >>> What can we test/reproduce the mentioned behavior? Or is there a way to >>> fix the >>> behavior of poll() or use an alternative of it? >>> >>> >>> OK to break on the 'POLLERR', I guess it can be detected in the >>> 'pfd.revent'. >>> >>> >>>> /* copy the tx frame data */ >>>> pbuf = (uint8_t *) ppd + TPACKET2_HDRLEN - >>>> sizeof(struct sockaddr_ll); >>>> >>> >>>