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.
--
ice_flow.c | 54 +++++++++++++++++++++++++++---------------------------
1 file changed, 26 insertions(+), 26 deletions(-)
Co-developed-by: Dan Nowlin <dan.nowlin@intel.com>
Signed-off-by: Dan Nowlin <dan.nowlin@intel.com>
Co-developed-by: Qi Zhang <qi.z.zhang@intel.com>
Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
Co-developed-by: Jie Wang <jie1x.wang@intel.com>
Signed-off-by: Jie Wang <jie1x.wang@intel.com>
Co-developed-by: Junfeng Guo <junfeng.guo@intel.com>
Signed-off-by: Junfeng Guo <junfeng.guo@intel.com>
Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
---
drivers/net/ethernet/intel/ice/ice_flow.c | 52 +++++++++++++++----------------
1 file changed, 26 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_flow.c b/drivers/net/ethernet/intel/ice/ice_flow.c
index 4513f1d6cec2..332551ad0bef 100644
--- a/drivers/net/ethernet/intel/ice/ice_flow.c
+++ b/drivers/net/ethernet/intel/ice/ice_flow.c
@@ -220,9 +220,9 @@ struct ice_flow_field_info ice_flds_info[ICE_FLOW_FIELD_IDX_MAX] = {
*/
static const u32 ice_ptypes_mac_ofos[] = {
0xFDC00846, 0xBFBF7F7E, 0xF70001DF, 0xFEFDFDFB,
- 0x0000077E, 0x00000000, 0x00000000, 0x00000000,
- 0x00400000, 0x03FFF000, 0x7FFFFFE0, 0x00000000,
- 0x00000000, 0x00000000, 0x00000000, 0x00000000,
+ 0x0000077E, 0x000003FF, 0x00000000, 0x00000000,
+ 0x00400000, 0x03FFF000, 0xFFFFFFE0, 0x00000707,
+ 0xFFFFF000, 0x000003FF, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
@@ -245,10 +245,10 @@ static const u32 ice_ptypes_macvlan_il[] = {
* include IPv4 other PTYPEs
*/
static const u32 ice_ptypes_ipv4_ofos[] = {
- 0x1DC00000, 0x04000800, 0x00000000, 0x00000000,
+ 0x1D800000, 0xBFBF7800, 0x000001DF, 0x00000000,
0x00000000, 0x00000155, 0x00000000, 0x00000000,
- 0x00000000, 0x000FC000, 0x00000000, 0x00000000,
- 0x00000000, 0x00000000, 0x00000000, 0x00000000,
+ 0x00000000, 0x000FC000, 0x000002A0, 0x00000000,
+ 0x00015000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
@@ -259,10 +259,10 @@ static const u32 ice_ptypes_ipv4_ofos[] = {
* IPv4 other PTYPEs
*/
static const u32 ice_ptypes_ipv4_ofos_all[] = {
- 0x1DC00000, 0x04000800, 0x00000000, 0x00000000,
+ 0x1D800000, 0x27BF7800, 0x00000000, 0x00000000,
0x00000000, 0x00000155, 0x00000000, 0x00000000,
- 0x00000000, 0x000FC000, 0x83E0F800, 0x00000101,
- 0x00000000, 0x00000000, 0x00000000, 0x00000000,
+ 0x00000000, 0x000FC000, 0x83E0FAA0, 0x00000101,
+ 0x3FFD5000, 0x00000000, 0x02FBEFBC, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
@@ -274,7 +274,7 @@ static const u32 ice_ptypes_ipv4_il[] = {
0xE0000000, 0xB807700E, 0x80000003, 0xE01DC03B,
0x0000000E, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x001FF800, 0x00000000,
- 0x00000000, 0x00000000, 0x00000000, 0x00000000,
+ 0xC0FC0000, 0x0000000F, 0xBC0BC0BC, 0x00000BC0,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
@@ -285,10 +285,10 @@ static const u32 ice_ptypes_ipv4_il[] = {
* include IPv6 other PTYPEs
*/
static const u32 ice_ptypes_ipv6_ofos[] = {
- 0x00000000, 0x00000000, 0x77000000, 0x10002000,
+ 0x00000000, 0x00000000, 0x76000000, 0x10002000,
0x00000000, 0x000002AA, 0x00000000, 0x00000000,
- 0x00000000, 0x03F00000, 0x00000000, 0x00000000,
- 0x00000000, 0x00000000, 0x00000000, 0x00000000,
+ 0x00000000, 0x03F00000, 0x00000540, 0x00000000,
+ 0x0002A000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
@@ -299,10 +299,10 @@ static const u32 ice_ptypes_ipv6_ofos[] = {
* IPv6 other PTYPEs
*/
static const u32 ice_ptypes_ipv6_ofos_all[] = {
- 0x00000000, 0x00000000, 0x77000000, 0x10002000,
- 0x00000000, 0x000002AA, 0x00000000, 0x00000000,
- 0x00080F00, 0x03F00000, 0x7C1F0000, 0x00000206,
- 0x00000000, 0x00000000, 0x00000000, 0x00000000,
+ 0x00000000, 0x00000000, 0x76000000, 0xFEFDE000,
+ 0x0000077E, 0x000002AA, 0x00000000, 0x00000000,
+ 0x00000000, 0x03F00000, 0x7C1F0540, 0x00000206,
+ 0xC002A000, 0x000003FF, 0xBC000000, 0x0002FBEF,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
@@ -314,7 +314,7 @@ static const u32 ice_ptypes_ipv6_il[] = {
0x00000000, 0x03B80770, 0x000001DC, 0x0EE00000,
0x00000770, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x7FE00000, 0x00000000,
- 0x00000000, 0x00000000, 0x00000000, 0x00000000,
+ 0x3F000000, 0x000003F0, 0x02F02F00, 0x0002F02F,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
@@ -387,8 +387,8 @@ static const u32 ice_ptypes_ipv6_il_no_l4[] = {
static const u32 ice_ptypes_udp_il[] = {
0x81000000, 0x20204040, 0x04000010, 0x80810102,
0x00000040, 0x00000000, 0x00000000, 0x00000000,
- 0x00000000, 0x00410000, 0x90842000, 0x00000007,
- 0x00000000, 0x00000000, 0x00000000, 0x00000000,
+ 0x00000000, 0x00410000, 0x908427E0, 0x00000007,
+ 0x0413F000, 0x00000041, 0x10410410, 0x00004104,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
@@ -400,7 +400,7 @@ static const u32 ice_ptypes_tcp_il[] = {
0x04000000, 0x80810102, 0x10000040, 0x02040408,
0x00000102, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00820000, 0x21084000, 0x00000000,
- 0x00000000, 0x00000000, 0x00000000, 0x00000000,
+ 0x08200000, 0x00000082, 0x20820820, 0x00008208,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
@@ -412,7 +412,7 @@ static const u32 ice_ptypes_sctp_il[] = {
0x08000000, 0x01020204, 0x20000081, 0x04080810,
0x00000204, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x01040000, 0x00000000, 0x00000000,
- 0x00000000, 0x00000000, 0x00000000, 0x00000000,
+ 0x10400000, 0x00000104, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
@@ -436,7 +436,7 @@ static const u32 ice_ptypes_icmp_il[] = {
0x00000000, 0x02040408, 0x40000102, 0x08101020,
0x00000408, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x42108000, 0x00000000,
- 0x00000000, 0x00000000, 0x00000000, 0x00000000,
+ 0x20800000, 0x00000208, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
@@ -448,7 +448,7 @@ static const u32 ice_ptypes_gre_of[] = {
0x00000000, 0xBFBF7800, 0x000001DF, 0xFEFDE000,
0x0000017E, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
- 0x00000000, 0x00000000, 0x00000000, 0x00000000,
+ 0x00000000, 0x00000000, 0xBEFBEFBC, 0x0002FBEF,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
@@ -457,7 +457,7 @@ static const u32 ice_ptypes_gre_of[] = {
/* Packet types for packets with an Innermost/Last MAC header */
static const u32 ice_ptypes_mac_il[] = {
- 0x00000000, 0x00000000, 0x00000000, 0x00000000,
+ 0x00000000, 0x20000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
@@ -471,7 +471,7 @@ static const u32 ice_ptypes_mac_il[] = {
static const u32 ice_ptypes_gtpc[] = {
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
- 0x00000000, 0x00000000, 0x00000180, 0x00000000,
+ 0x00000000, 0x00000000, 0x000001E0, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
--
2.51.0.rc1.197.g6d975e95c9d7On 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.
Also, the two lines below seem out of place.
> ice_flow.c | 54 +++++++++++++++++++++++++++---------------------------
> 1 file changed, 26 insertions(+), 26 deletions(-)
>
> Co-developed-by: Dan Nowlin <dan.nowlin@intel.com>
> Signed-off-by: Dan Nowlin <dan.nowlin@intel.com>
> Co-developed-by: Qi Zhang <qi.z.zhang@intel.com>
> Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
> Co-developed-by: Jie Wang <jie1x.wang@intel.com>
> Signed-off-by: Jie Wang <jie1x.wang@intel.com>
> Co-developed-by: Junfeng Guo <junfeng.guo@intel.com>
> Signed-off-by: Junfeng Guo <junfeng.guo@intel.com>
> Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
> Reviewed-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
> Reviewed-by: Simon Horman <horms@kernel.org>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_flow.c | 52 +++++++++++++++----------------
> 1 file changed, 26 insertions(+), 26 deletions(-)
...
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.
I fixed this on my end, and can resubmit after the 24hr period if needed.
Thanks,
Jake
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.
> 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.
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.
On Thu, 16 Oct 2025 14:37:53 -0700 Jacob Keller wrote: > 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?). Looks like patchwork, it serves us: https://patchwork.kernel.org/project/netdevbpf/patch/20251015-jk-iwl-next-2025-10-15-v1-6-79c70b9ddab8@intel.com/mbox which has the -- "corrected" to --- Doesn't matter all that much cause there are also kdoc issues on patches 4 and 5. Obligatory advertisement: https://github.com/linux-netdev/nipa?tab=readme-ov-file#running-locally -- pw-bot: cr
On 10/16/2025 4:56 PM, Jakub Kicinski wrote: > On Thu, 16 Oct 2025 14:37:53 -0700 Jacob Keller wrote: >> 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?). > > Looks like patchwork, it serves us: > https://patchwork.kernel.org/project/netdevbpf/patch/20251015-jk-iwl-next-2025-10-15-v1-6-79c70b9ddab8@intel.com/mbox > which has the -- "corrected" to --- > That seems like a patchwork issue which should be corrected, in the event that someone accidentally or intentionally uses '--' in their commit message. > Doesn't matter all that much cause there are also kdoc issues on > patches 4 and 5. Obligatory advertisement: > https://github.com/linux-netdev/nipa?tab=readme-ov-file#running-locally ._. yep. Turns out our NIPA automation was down while Tony was out and I didn't get emails, but didn't think to double check that I got passing results either... Hooray.
On 10/16/2025 5:31 PM, Jacob Keller wrote: > On 10/16/2025 4:56 PM, Jakub Kicinski wrote: >> Oligatory advertisement: >> https://github.com/linux-netdev/nipa?tab=readme-ov-file#running-locally > Got this setup locally, its pretty good, though it is a bit slower than I expected at getting everything compile-tested. Took long enough I stepped away before coming back a few hours later. It would be convenient of it showed some sort of progress. I've got some ideas on improving some of the tests (kdoc in particular) which I'll look into soon as well. Cheers, Jake
© 2016 - 2025 Red Hat, Inc.