On 10/16/2025 12:03 PM, Simon Horman wrote:

On Thu, Oct 16, 2025 at 10:20:25AM -0700, Jacob Keller wrote:

quoted

On 10/16/2025 5:21 AM, Simon Horman wrote:

quoted

On Wed, Oct 15, 2025 at 12:32:02PM -0700, Jacob Keller wrote:

quoted

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.

quoted

Also, the two lines below seem out of place.

quoted

 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/ (local)

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.

quoted

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.