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 Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1228AC02198 for ; Fri, 14 Feb 2025 11:20:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 9E1CD83A73; Fri, 14 Feb 2025 11:20:24 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id zFbV4TnGBXAZ; Fri, 14 Feb 2025 11:20:23 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=140.211.166.142; helo=lists1.osuosl.org; envelope-from=intel-wired-lan-bounces@osuosl.org; receiver= DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 9715683AD9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osuosl.org; s=default; t=1739532023; bh=9l3d5h97w8JyBfnaFKOZUCgbofNi5r9Nz0RaWVnwioM=; h=Date:To:Cc:References:From:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=MJwN76B3B2+wApbrtNzFgSrTL0vLrrAdTEitotBFDRZX0MYiH0nQZgkSobaGm6k51 wJr5EiDjBqhorES202CgpzKldJ1R5/AqOkys1LNANeIAwUdsFWrSlJFJeEU6c+erDN YSlXF//f0kqfDnb4rG+IlSjdC3EzpYUSkz35nr4A8+rTsBJKvsTMfebw1quooyHFEI 0Fc6i/uy+SgsS3YUeS8DdnJwHRmJmHBJYWkYFlWmZJm08Pb8oKWe1PPNr+blJEqi3n sd4+9e2dfG0fRhs47jthjgygeTxl1Zio42ltNXVf48garCtrSFhrRGtu0Z41FzwF/W bjLRqyAl4cQVg== Received: from lists1.osuosl.org (lists1.osuosl.org [140.211.166.142]) by smtp1.osuosl.org (Postfix) with ESMTP id 9715683AD9; Fri, 14 Feb 2025 11:20:23 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists1.osuosl.org (Postfix) with ESMTP id 6D510C2 for ; Fri, 14 Feb 2025 11:20:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 501D783AD4 for ; Fri, 14 Feb 2025 11:20:21 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id fi9eNor2Lu38 for ; Fri, 14 Feb 2025 11:20:20 +0000 (UTC) Received-SPF: None (mailfrom) identity=mailfrom; client-ip=192.198.163.9; helo=mgamail.intel.com; envelope-from=faizal.abdul.rahim@linux.intel.com; receiver= DMARC-Filter: OpenDMARC Filter v1.4.2 smtp1.osuosl.org E166283981 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org E166283981 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) by smtp1.osuosl.org (Postfix) with ESMTPS id E166283981 for ; Fri, 14 Feb 2025 11:20:19 +0000 (UTC) X-CSE-ConnectionGUID: gDHrNqbRRuiJBCvaWEltdg== X-CSE-MsgGUID: ShYgltDqS9ybJxnqTiWMPQ== X-IronPort-AV: E=McAfee;i="6700,10204,11344"; a="50921228" X-IronPort-AV: E=Sophos;i="6.13,285,1732608000"; d="scan'208";a="50921228" Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Feb 2025 03:20:19 -0800 X-CSE-ConnectionGUID: y7/+bKRnQVCJqHfK1+vedw== X-CSE-MsgGUID: e3HzIYJQSCC/jYLkKMQc/Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.13,285,1732608000"; d="scan'208";a="113624859" Received: from mohdfai2-mobl.gar.corp.intel.com (HELO [10.247.89.75]) ([10.247.89.75]) by fmviesa008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Feb 2025 03:20:11 -0800 Message-ID: Date: Fri, 14 Feb 2025 19:20:08 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Vladimir Oltean Cc: Kurt Kanzenbach , Tony Nguyen , Przemek Kitszel , Andrew Lunn , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Maxime Coquelin , Alexandre Torgue , Simon Horman , Russell King , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , Furong Xu <0x1207@gmail.com>, Russell King , Serge Semin , Xiaolei Wang , Suraj Jaiswal , Kory Maincent , Gal Pressman , Jesper Nilsson , Choong Yong Liang , Kunihiko Hayashi , Vinicius Costa Gomes , intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, bpf@vger.kernel.org References: <87cyfmnjdh.fsf@kurt.kurt.home> <5902cc28-a649-4ae9-a5ba-83aa265abaf8@linux.intel.com> <20250213130003.nxt2ev47a6ppqzrq@skbuf> <1c981aa1-e796-4c53-9853-3eae517f2f6d@linux.intel.com> <877c5undbg.fsf@kurt.kurt.home> <20250213184613.cqc2zhj2wkaf5hn7@skbuf> <87v7td3bi1.fsf@kurt.kurt.home> <874j0wrjk2.fsf@kurt.kurt.home> <641ab972-e110-4af2-ad9b-6688cee56562@linux.intel.com> <20250214102206.25dqgut5tbak2rkz@skbuf> Content-Language: en-US From: "Abdul Rahim, Faizal" In-Reply-To: <20250214102206.25dqgut5tbak2rkz@skbuf> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1739532020; x=1771068020; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=bsMoByqwV8q04F4BIn7mVkZvxnRBIcre3Xld+Gy6r0M=; b=VEAcjJIvFJxUj3JHJa8hqqc3ETNBTRupaiK4U0zddaSVQ8F9OPBOCeST xp01eH9jJ73k88Z+8zXxdF2acGkXFV9X5DnemhmY7VIVbUYEPYY90to/a 5d2gYHkU0koLcsoaSbGqujD7Kd23tfpZX9/iOD/lg9mPs2axMT3iHgZGW HRHkvajlEFIdBIjcf5EFVOE2CQtxKG12b7icK/r5918KlDLZodLnVygpk EEbTym7h+cpBVfRlTzzf1S2YbyDSWmKrn+3iXzRmMSQ+qX46FY32khrA4 dl3vwgxY9Z9/ucb/SEibZjVbUi0dVfd109rPBosJQrFFP+M6+Vg4Y9W77 g==; X-Mailman-Original-Authentication-Results: smtp1.osuosl.org; dmarc=none (p=none dis=none) header.from=linux.intel.com X-Mailman-Original-Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=VEAcjJIv Subject: Re: [Intel-wired-lan] [PATCH iwl-next v4 0/9] igc: Add support for Frame Preemption feature in IGC X-BeenThere: intel-wired-lan@osuosl.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Intel Wired Ethernet Linux Kernel Driver Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-wired-lan-bounces@osuosl.org Sender: "Intel-wired-lan" On 14/2/2025 6:22 pm, Vladimir Oltean wrote: > Faizal, > > On Fri, Feb 14, 2025 at 05:43:19PM +0800, Abdul Rahim, Faizal wrote: >>>> Hi Kurt & Vladimir, >>>> >>>> After reading Vladimir's reply on tc, hw queue, and socket priority mapping >>>> for both taprio and mqprio, I agree they should follow the same priority >>>> scheme for consistency—both in code and command usage (i.e., taprio, >>>> mqprio, and fpe in both configurations). Since igc_tsn_tx_arb() ensures a >>>> standard mapping of tc, socket priority, and hardware queue priority, I'll >>>> enable taprio to use igc_tsn_tx_arb() in a separate patch submission. >>> >>> There's one point to consider here: igc_tsn_tx_arb() changes the mapping >>> between priorities and Tx queues. I have no idea how many people rely on >>> the fact that queue 0 has always the highest priority. For example, it >>> will change the Tx behavior for schedules which open multiple traffic >>> classes at the same time. Users may notice. >> >> Yeah, I was considering the impact on existing users too. I hadn’t given it >> much thought initially and figured they’d just need to adapt to the changes, >> but now that I think about it, properly communicating this would be tough. >> taprio on igc (i225, i226) has been around for a while, so a lot of users >> would be affected. >> >>> OTOH changing mqprio to the broken_mqprio model is easy, because AFAIK >>> there's only one customer using this. >>> >> >> Hmmmm, now I’m leaning toward keeping taprio as is (hw queue 0 highest >> priority) and having mqprio follow the default priority scheme (aka >> broken_mqprio). Even though it’s not the norm, the impact doesn’t seem worth >> the gain. Open to hearing others' thoughts. > > Kurt is right, you need to think about your users, but it isn't only that. > Intel puts out a lot of user-facing TSN technical documentation for Linux, > and currently, they have a hard time adapting it to other vendors, because > of Intel specific peculiarities such as this one. I would argue that for > being one of the most visible vendors from the Linux TSN space, you also > have a duty to the rest of the community of not pushing users away from > established conventions. > > It's unfair that a past design mistake would stifle further evolution of > the driver in the correct direction, so I don't think we should let that > happen. I was thinking the igc driver should have a driver-specific > opt-in flag which users explicitly have to set in order to get the > conventional TX scheduling behavior in taprio (the one from mqprio). > Public Intel documentation would be updated to present the differences > between the old and the new mode, and to recommend opting into the new > mode. By default, the current behavior is maintained, thus not breaking > any user. Something like an ethtool priv flag seems adequate for this. > > Understandably, many network maintainers will initially dislike this, > but you will have to be persistent and explain the ways in which having > this priv flag is better than not having it. Normally they will respect > those reasons more than they dislike driver-specific priv flags, which, > let's be honest, are way too often abused for adding custom behavior. > Here the situation is different, the custom behavior already exists, it > just doesn't have a name and there's no way of turning it off. Okay. I can look into this in a separate patch submission, but just an FYI—this adds another dependency to the second part of the igc fpe submission (preemptible tc on taprio + mqprio). This new patch (driver-specific priv flag to control 2 different priority scheme) would need to be accepted first before the second part of igc fpe can be submitted.