Remove flow type enum

[PlagueCZ]

Motivation

I wanted to include enum flow_type into the dataplane schema, because DP_FLOW_TYPE_INCOMING is really important for packet traversal. But I could not find a good way to do it, which seemed odd, because what the value represents is really simple.

I found out that by removing it and instead using src_port->is_pf instead (and dst_port->is_pf for DP_FLOW_TYPE_OUTGOING respectively) really simplified everything. This also "solves" the strange state in loadbalancer recirculation where the flow actually is both incoming and outgoing at the same time.

Changes

Of course nothing really changed functionally (as using two booleans vs. one 2-bit wide enum is exactly the same amount of information), but in the code everything really clicked for me and the schema only needed a light touch to include this now.

This also enabled me to simplify code in ipv4_lookup and I made ipv6_lookup to look almost the same, which will be good in the future.

As a separate commit I also replaced enum port_type with a boolean, because port->port_type == DP_PORT_PF is harder to read than port->is_pf and this also removes the need for switch (port->type) etc.

[guvenc]

Hmm. This is not really equivalent to non-refactored version, right ? DP_FLOW_TYPE_LOCAL case was causing a dropped packet in previous version but now it goes to virtsvc_request_next.
Can this happen in other parts of the code because DP_FLOW_TYPE_LOCAL is eliminated ?

[PlagueCZ]

You are right on the else covering more types of flow_type, but in CLS this was always either set to INCOMING or OUTGOING based on a match of src/dst IPv6. What the node really needs to know is the direction to/from service. (I thought about splitting the node into two, and depending on the future of this feature I still have it as a point to think about.)

[PlagueCZ]

I think there is a problem with the change in dp_rte_flow_traffic_forward(), in packet-relay type of communication. I'll investigate further

[byteocean]

this seems to eliminate the possibility to perform offloading for in-network NAT and LB flow bouncing. For both cases, both incoming_port->is_pf and outgoing_port->is_pf are true, and an error is thrown here. (!incoming_port->is_pf && !outgoing_port->is_pf) could be an alternative, but the subsequential conditions also need to be reconsidered.

[PlagueCZ]

I had to re-order the code since OUTGOING always had priority before (it changed INCOMING to OOUTGOING in the enum).

I also added checks as I understande the code, but please check that. Maybe they are not needed or maybe the test for df->conntrack->nf_info.nat_type is not needed? Then we could simplify the code to only ask the is_pf and be nat_type agnostic, which would be more readable locally, but maybe would miss the point of the architecture.

[guvenc]

@byteocean @PlagueCZ
Looks like this one needs a rebase and does this PR have the latest corrections in the offloading path ? and can be seen as mature to be considered for another short review and merge ?

[PlagueCZ]

@guvenc I rebased onto #429 (which has been rebased onto main with attached removal). I think only that fix and the last commit here to improve offloading installer function was all that was needed. So it is ready for another review now.

[guvenc]

Looks good to me