From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6972142AAF; Fri, 14 Feb 2025 04:50:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739508619; cv=none; b=gMmbRtVXkfuS41WCQpjm8ZXUBaLMZxiOaUICtHW5+IlHiubpOORZaW3z+i5nxlcv+7u1S/skgp1yat91Ge17tx/FuJ7QqvkOMC/dSztTaxRA7h3WqyjDMT0vV+gnCL7ytfC7gK9wMoIgA2zrGOMqOHVwNCSWKitC4w3dyix1GC0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739508619; c=relaxed/simple; bh=gPVj4mO6xQJrCt3sZYWJNbH9C8SimtbKXR7wY1fjf90=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=SfltRmKOiw5sz1HQg9km8aSfBgAe1dSK7bCqmvFVg+2PxTYBA+eJNZF0pUSrQmArkxneJ7jZpcSdZhU3z18eEevM2GUWkgujQcs2Yx5fCqpsx7j1lTyS1KxtoI1+j3KXEZa4H4inpHSpDWCGwdKWvbZ2TltB+b+OboBZt5KuLyU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=JorwI9bI; arc=none smtp.client-ip=198.175.65.18 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="JorwI9bI" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1739508618; x=1771044618; h=message-id:date:mime-version:subject:from:to:cc: references:in-reply-to:content-transfer-encoding; bh=gPVj4mO6xQJrCt3sZYWJNbH9C8SimtbKXR7wY1fjf90=; b=JorwI9bIUscB+rO2CNT6mhd6Aej2x39pdqMJ4kV/Svc0iULJQFsnsrRa Mj51M5DpENNxBU3lHUXBBEOTQDiaBBY0GnS1wl2kvrx9akq1jeyV0UlM8 o+VRAtN/moCQTNt+Bi/pvCoN3JTKnPyYrBqiSQrkJgpfmbPb6OEPk6PB4 kF7g8s057LUA3Kw+vXNJP1mys2Y+DJXn4FjVndzs5wMKYerNqTKN6IMkI 5QbzxYSHBbpQMIntK2H3rL+SKs91L7JQ1xLbanLAgeXDCGvqchEKPGQ6x B2ED/Ii7sTOcmx6yRdck7j6ukRXknGaXIVtDTEoQT4bMMwwPc+FUZK+Yo w==; X-CSE-ConnectionGUID: u7AS2e6uShGQvvfrlgPHgA== X-CSE-MsgGUID: 65PyX/SOR6CSShPK05QAYQ== X-IronPort-AV: E=McAfee;i="6700,10204,11314"; a="40361826" X-IronPort-AV: E=Sophos;i="6.12,310,1728975600"; d="scan'208";a="40361826" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Feb 2025 20:50:15 -0800 X-CSE-ConnectionGUID: 2b+fgtn9Q7+FDC4KwavSPQ== X-CSE-MsgGUID: wezvzmt3Tm6HcUS0QIfqlQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.13,284,1732608000"; d="scan'208";a="113096903" Received: from mohdfai2-mobl.gar.corp.intel.com (HELO [10.247.123.6]) ([10.247.123.6]) by orviesa009-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Feb 2025 20:50:07 -0800 Message-ID: Date: Fri, 14 Feb 2025 12:50:04 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH iwl-next v4 0/9] igc: Add support for Frame Preemption feature in IGC From: "Abdul Rahim, Faizal" To: Kurt Kanzenbach , Vladimir Oltean Cc: 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 , Andrew Halaney , 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: <20250210070207.2615418-1-faizal.abdul.rahim@linux.intel.com> <20250210070207.2615418-1-faizal.abdul.rahim@linux.intel.com> <20250212220121.ici3qll66pfoov62@skbuf> <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> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 14/2/2025 12:20 pm, Abdul Rahim, Faizal wrote: > > > On 14/2/2025 3:12 am, Kurt Kanzenbach wrote: >> On Thu Feb 13 2025, Vladimir Oltean wrote: >>> So, confusingly to me, it seems like one operating mode is fundamentally >>> different from the other, and something will have to change if both will >>> be made to behave the same. What will change? You say mqprio will behave >>> like taprio, but I think if anything, mqprio is the one which does the >>> right thing, in igc_tsn_tx_arb(), and taprio seems to use the default Tx >>> arbitration scheme? >> >> Correct. taprio is using the default scheme. mqprio configures it to >> what ever the user provided (in igc_tsn_tx_arb()). >> >>> I don't think I'm on the same page as you guys, because to me, it is >>> just odd that the P traffic classes would be the first ones with >>> mqprio, but the last ones with taprio. >> >> I think we are on the same page here. At the end both have to behave the >> same. Either by using igc_tsn_tx_arb() for taprio too or only using the >> default scheme for both (and thereby keeping broken_mqprio). Whatever >> Faizal implements I'll match the behavior with mqprio. >> > > 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. > > I'll split the changes based on Vladimir's suggestion. > > First part - ethtool-mm related: > igc: Add support to get frame preemption statistics via ethtool > igc: Add support to get MAC Merge data via ethtool > igc: Add support to set tx-min-frag-size > igc: Add support for frame preemption verification > igc: Set the RX packet buffer size for TSN mode > igc: Optimize TX packet buffer utilization > igc: Rename xdp_get_tx_ring() for non-XDP usage > net: ethtool: mm: Extract stmmac verification logic into a common library > > Second part: > igc: Add support for preemptible traffic class in taprio and mqprio > igc: Use igc_tsn_tx_arb() for taprio queue priority scheme > igc: Kurt's patch on mqprio to use normal TSN Tx mode > > Kurt can keep igc_tsn_tx_arb() for his mqprio patch, so preemptible tc > should work the same for both taprio and mqprio. > > I'm suggesting to include Kurt's patch in the second part since there's > some dependency and potential code conflict, even though it mixes different > functional changes in the same series. I forgot that the second part patch: igc: Add support for preemptible traffic class in taprio and mqprio depends on the first part ethtool-mm, which would delay Kurt's patch. So Kurt, if you'd prefer to submit yours first, that's okay too.