Re: [PATCH net-next 06/14] ice: Extend PTYPE bitmap coverage for GTP encapsulated flows

[Jacob Keller <jacob.e.keller@intel.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3855 bytes --]



On 10/16/2025 12:03 PM, Simon Horman wrote:
> On Thu, Oct 16, 2025 at 10:20:25AM -0700, Jacob Keller wrote:
>>
>>
>> On 10/16/2025 5:21 AM, Simon Horman wrote:
>>> On Wed, Oct 15, 2025 at 12:32:02PM -0700, Jacob Keller wrote:
>>>> From: Przemek Kitszel <przemyslaw.kitszel@intel.com>
>>>>
>>>> Consolidate updates to the Protocol Type (PTYPE) bitmap definitions
>>>> across multiple flow types in the Intel ICE driver to support GTP
>>>> (GPRS Tunneling Protocol) encapsulated traffic.
>>>>
>>>> Enable improved Receive Side Scaling (RSS) configuration for both user
>>>> and control plane GTP flows.
>>>>
>>>> Cover a wide range of protocol and encapsulation scenarios, including:
>>>>  - MAC OFOS and IL
>>>>  - IPv4 and IPv6 (OFOS, IL, ALL, no-L4)
>>>>  - TCP, SCTP, ICMP
>>>>  - GRE OF
>>>>  - GTPC (control plane)
>>>>
>>>> Expand the PTYPE bitmap entries to improve classification and
>>>> distribution of GTP traffic across multiple queues, enhancing
>>>> performance and scalability in mobile network environments.
>>>>
>>>> --
>>>
>>> Hi Jacob,
>>>
>>> Perhaps surprisingly, git truncates the commit message at
>>> the ('--') line above. So, importantly, the tags below are absent.
>>>
>>
>> Its somewhat surprising, since I thought you had to use '---' for that.
>> Regardless, this shouldn't be in the commit message at all.
>>> Also, the two lines below seem out of place.
>>>
>>>>  ice_flow.c |   54 +++++++++++++++++++++++++++---------------------------
>>>>  1 file changed, 26 insertions(+), 26 deletions(-)
>>>>
>>
>> Yep these shouldn't have been here at all. I checked, and for some
>> reason it was included in the original message id of the patch. b4
>> happily picked it up when using b4 shazam.
>>
>> See:
>> https://lore.kernel.org/intel-wired-lan/20250915133928.3308335-5-aleksandr.loktionov@intel.com/
>>
>> I am not sure if this is the fault of b4, though it has different
>> behavior than other git tooling here.
> 
> TBH, I am also surprised that git truncates at '--'. I also thought
> '---'. And as this is the second time it's come up recently,
> while I don't recall seeing it before, perhaps due to some tooling change
> somewhere: e.g. interaction between git and b4.
> 

Hm. Looking into this more, since I wanted to figure out how *I* got
those in my commit.

I checked the original message posted to Intel Wired LAN, and the
contents are there.

Git says:

>        The patch is expected to be inline, directly following the message. Any line that is of the form:
> 
>        •   three-dashes and end-of-line, or
> 
>        •   a line that begins with "diff -", or
> 
>        •   a line that begins with "Index: "
> 
>        is taken as the beginning of a patch, and the commit log message is terminated before the first occurrence of such a line.

This is only 2 dashes, so it shouldn't trigger the 3-dash rule. Indeed,
if I use b4 shazam, I get these lines in the commit message. (That
explains how it ended up on my tree when I submitted).

If I use git format-patch on this commit, I get the lines in the file.
If I then use git am to apply the formatted patch file, I indeed still
keep these lines in the commit message.

What version of git are you using? I'm using git v2.51.0 Perhaps this
isn't a b4 or git issue but some other tooling that is causing an issue
(patchwork?).

At least on my system I do actually preserve the lines below '--', and
it is not until '---' which it will start stripping data.
>> I fixed this on my end, and can resubmit after the 24hr period if needed.
> 
> FWIIW, I'd lean towards reposting after 24h if you don't hear from one of
> the maintainers.
> 
> 

Obviously, we shouldn't need these lines in the commit message, so I
will still send a v2 and drop the cruft.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]