Upon reviewing the flower control flags handling in
this driver, I notice that the key wasn't being used,
only the mask.

Ie. `tc flower ... ip_flags nofrag` was hardware
offloaded as `... ip_flags frag`.

Only compile tested, no access to HW.

Fixes: c672e3727989 ("octeontx2-pf: Add support to filter packet based on IP fragment")
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
---

This is a best guess on a fix, I don't know if it will work,
but hopefully someone at Marvell can test it.

The more certain alternative would be to set an error msg.
and return -EOPNOTSUPP, when `tc flower ip_flags nofrag`
is used.

 drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c
index 87bdb93cb066e..f4655a8c0705d 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c
@@ -688,22 +688,25 @@ static int otx2_tc_prepare_flow(struct otx2_nic *nic, struct otx2_tc_flow *node,
 	}
 
 	if (flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_CONTROL)) {
 		struct flow_match_control match;
+		u32 val;
 
 		flow_rule_match_control(rule, &match);
 		if (match.mask->flags & FLOW_DIS_FIRST_FRAG) {
 			NL_SET_ERR_MSG_MOD(extack, "HW doesn't support frag first/later");
 			return -EOPNOTSUPP;
 		}
 
 		if (match.mask->flags & FLOW_DIS_IS_FRAGMENT) {
+			val = match.key->flags & FLOW_DIS_IS_FRAGMENT;
 			if (ntohs(flow_spec->etype) == ETH_P_IP) {
-				flow_spec->ip_flag = IPV4_FLAG_MORE;
+				flow_spec->ip_flag = val ? IPV4_FLAG_MORE : 0;
 				flow_mask->ip_flag = IPV4_FLAG_MORE;
 				req->features |= BIT_ULL(NPC_IPFRAG_IPV4);
 			} else if (ntohs(flow_spec->etype) == ETH_P_IPV6) {
-				flow_spec->next_header = IPPROTO_FRAGMENT;
+				flow_spec->next_header = val ?
+							 IPPROTO_FRAGMENT : 0;
 				flow_mask->next_header = 0xff;
 				req->features |= BIT_ULL(NPC_IPFRAG_IPV6);
 			} else {
 				NL_SET_ERR_MSG_MOD(extack, "flow-type should be either IPv4 and IPv6");
-- 
2.43.0

On Wed, 10 Apr 2024 13:43:01 +0000 Asbjørn Sloth Tønnesen wrote:
> Upon reviewing the flower control flags handling in
> this driver, I notice that the key wasn't being used,
> only the mask.
> 
> Ie. `tc flower ... ip_flags nofrag` was hardware
> offloaded as `... ip_flags frag`.
> 
> Only compile tested, no access to HW.
> 
> Fixes: c672e3727989 ("octeontx2-pf: Add support to filter packet based on IP fragment")
> Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>

Marvell folks, please provide timely review.
It is your duty as documented in
Documentation/maintainer/feature-and-driver-maintainers.rst

On 4/10/2024 6:43 AM, Asbjørn Sloth Tønnesen wrote:
> Upon reviewing the flower control flags handling in
> this driver, I notice that the key wasn't being used,
> only the mask.
> 
> Ie. `tc flower ... ip_flags nofrag` was hardware
> offloaded as `... ip_flags frag`.
> 
> Only compile tested, no access to HW.
> 
> Fixes: c672e3727989 ("octeontx2-pf: Add support to filter packet based on IP fragment")
> Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
> ---
> 

I know nothing about this hardware, but the change does match your
description. Hopefully someone from Marvell can comment on the hardware
aspect.

Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>

> This is a best guess on a fix, I don't know if it will work,
> but hopefully someone at Marvell can test it.
> 
> The more certain alternative would be to set an error msg.
> and return -EOPNOTSUPP, when `tc flower ip_flags nofrag`
> is used.