net/bnxt: support tunnel offload

Add support for tunnel offload APIs. Specifically the following
are supported.
tunnel_decap_set, tunnel_match, tunnel_action_decap_release,
tunnel_item_release.

Thi

net/bnxt: support tunnel offload

Add support for tunnel offload APIs. Specifically the following
are supported.
tunnel_decap_set, tunnel_match, tunnel_action_decap_release,
tunnel_item_release.

This provides support for VXLAN decap action where two flows
can indicate tunnel offload rule. The first flow indicates the
tunnel properties and second flow indicates the inner packet
structure. The templates are updated to support this
feature.

Signed-off-by: Kishore Padmanabha <[email protected]>
Signed-off-by: Venkat Duvvuru <[email protected]>
Reviewed-by: Shahaji Bhosle <[email protected]>
Acked-by: Ajit Khaparde <[email protected]>

show more ...

net/bnxt: support flow template for Thor

Template adds non-VFR based support for testpmd with:
matches to include
- DMAC, SIP, DIP, Proto, Sport, Dport
- SIP, DIP, Proto, Sport, Dport
actions:
- cou

net/bnxt: support flow template for Thor

Template adds non-VFR based support for testpmd with:
matches to include
- DMAC, SIP, DIP, Proto, Sport, Dport
- SIP, DIP, Proto, Sport, Dport
actions:
- count, drop

Signed-off-by: Kishore Padmanabha <[email protected]>
Signed-off-by: Venkat Duvvuru <[email protected]>
Reviewed-by: Mike Baucom <[email protected]>
Acked-by: Ajit Khaparde <[email protected]>

show more ...

net/bnxt: refactor ULP mapper

1. The internal and external exact match table resource types
is combined since the resource handle contains the encoded
type whether it is internal or external exact m

net/bnxt: refactor ULP mapper

1. The internal and external exact match table resource types
is combined since the resource handle contains the encoded
type whether it is internal or external exact match entry.

2. When a flow doesn't hit the offloaded rules, the default action is
to send it to the kernel (L2 driver interface). In order to do that,
TRUFLOW must know the kernel interface's (PF's) default vnic id.
This patch fetches the PF's default vnic id from the dpdk core and
stores it in port database. It also stores the mac addr for the
future usage. Renamed compute field for layer 4 port enums.
Added support for port database opcode that can get port details
like mac address which can then be populated in the l2 context entry.

3. Both active and default bit set need to considered to check if a
specific flow type is enabled or not.

4. ulp mapper fetches the dpdk port id from the compute field index
BNXT_ULP_CF_IDX_DEV_PORT_ID which is used to get the interface’s
mac address eventually. However, the compute field array is not
populated with dpdk port id at the index BNXT_ULP_CF_IDX_DEV_PORT_ID.
The problem fixed by populating the compute field array correctly.

5. Some dpdk applications may accumulate the flow counters while some
may not. In cases where the application is accumulating the counters
the PMD need not do the accumulation itself and viceversa to report
the correct flow counters.

6. Pointer to bp is added to open session parms to support
shared session.

Signed-off-by: Venkat Duvvuru <[email protected]>
Signed-off-by: Kishore Padmanabha <[email protected]>
Signed-off-by: Jay Ding <[email protected]>
Reviewed-by: Lance Richardson <[email protected]>
Reviewed-by: Mike Baucom <[email protected]>
Reviewed-by: Ajit Khaparde <[email protected]>
Reviewed-by: Somnath Kotur <[email protected]>
Reviewed-by: Randy Schacher <[email protected]>

show more ...

net/bnxt: add conditional goto processing

The condition execute of the mapper tables have goto field that
defines the offset of the next table to be processed instead of
sequential processing of the

net/bnxt: add conditional goto processing

The condition execute of the mapper tables have goto field that
defines the offset of the next table to be processed instead of
sequential processing of the tables, this improving the performance.
Also, modify key and mask field opcode processing

Signed-off-by: Kishore Padmanabha <[email protected]>
Signed-off-by: Venkat Duvvuru <[email protected]>
Reviewed-by: Mike Baucom <[email protected]>
Reviewed-by: Ajit Khaparde <[email protected]>

show more ...

net/bnxt: identify duplicate flows

Conflict resolution feature allows rejection of flows based on
the previously added flows that conflict. For instance, a five
tuple flow is added and then you add

net/bnxt: identify duplicate flows

Conflict resolution feature allows rejection of flows based on
the previously added flows that conflict. For instance, a five
tuple flow is added and then you add a new flow with only 4 tuple
instead having same layer2 details then it will be rejected.

Signed-off-by: Kishore Padmanabha <[email protected]>
Signed-off-by: Venkat Duvvuru <[email protected]>
Reviewed-by: Mike Baucom <[email protected]>
Reviewed-by: Ajit Khaparde <[email protected]>

show more ...

net/bnxt: modify VXLAN decap for multichannel mode

The driver is using physical port id as the index into
the tunnel inner flow table. However, this will not work in case
of multichannel mode where

net/bnxt: modify VXLAN decap for multichannel mode

The driver is using physical port id as the index into
the tunnel inner flow table. However, this will not work in case
of multichannel mode where multiple physical functions are going
to share the same physical port id.

When tunnel inner flow offload request comes before tunnel
outer flow offload request, the driver caches the tunnel inner flow
details and programs it in the hardware after installing the tunnel
outer flow in the hardware. If more than one tunnel inner flow arrives
before tunnel outer flow is offloaded, the driver rejects any such
tunnel inner flow offload requests.

This patch fixes the above two problems by
1. Using dpdk port id as the index to store tunnel inner info.
2. Caching any number of tunnel inner flow offload requests that come
before offloading tunnel outer flow offload request

Signed-off-by: Venkat Duvvuru <[email protected]>
Reviewed-by: Shahaji Bhosle <[email protected]>
Reviewed-by: Ajit Khaparde <[email protected]>

show more ...

net/bnxt: update copyright year

Update copyright year in various files.

Signed-off-by: Ajit Khaparde <[email protected]>
Reviewed-by: Somnath Kotur <[email protected]>
Reviewed-by

net/bnxt: update copyright year

Update copyright year in various files.

Signed-off-by: Ajit Khaparde <[email protected]>
Reviewed-by: Somnath Kotur <[email protected]>
Reviewed-by: Kalesh AP <[email protected]>

show more ...

net/bnxt: fix VXLAN decap offload

This patch fixes a couple of scenarios which were overlooked
by the patch which added VXLAN rte_flow offload support.

1. When a PMD application queries for flow co

net/bnxt: fix VXLAN decap offload

This patch fixes a couple of scenarios which were overlooked
by the patch which added VXLAN rte_flow offload support.

1. When a PMD application queries for flow counters, it could ask PMD
to reset the counters when the application is doing the counters
accumulation. In this case, PMD should not accumulate rather reset
the counter.

2. Some of the PMD applications may set the protocol field in the IPv4
spec but don't set the mask. So, consider the mask in the proto
value calculation.

4. The cached tunnel inner flow is not getting installed in the
context of tunnel outer flow create because of the wrong
error code check when tunnel outer flow is installed in the
hardware.

5. When a dpdk application offloads the same tunnel inner flow on
all the uplink ports, other than the first one the driver rejects
the rest of them. However, the first tunnel inner flow request
might not be of the correct physical port. This is fixed by
caching the tunnel inner flow entry for all the ports on which
the flow offload request has arrived on. The tunnel inner flows
which were cached on the irrelevant ports will eventually get
aged out as there won't be any traffic on these ports.

Fixes: 675e31d877b6 ("net/bnxt: support VXLAN decap offload")

Signed-off-by: Venkat Duvvuru <[email protected]>
Reviewed-by: Ajit Khaparde <[email protected]>
Reviewed-by: Somnath Kotur <[email protected]>

show more ...

net/bnxt: support VXLAN decap offload

VXLAN decap offload can happen in stages. The offload request may
not come as a single flow request rather may come as two flow offload
requests F1 & F2. This p

net/bnxt: support VXLAN decap offload

VXLAN decap offload can happen in stages. The offload request may
not come as a single flow request rather may come as two flow offload
requests F1 & F2. This patch is adding support for this two stage
offload design. The match criteria for F1 is O_DMAC, O_SMAC,
O_DST_IP, O_UDP_DPORT and actions are COUNT, MARK, JUMP. The match
criteria for F2 is O_SRC_IP, O_DST_IP, VNI and inner header fields.
F1 and F2 flow offload requests can come in any order. If F2 flow
offload request comes first then F2 can’t be offloaded as there is
no O_DMAC information in F2. In this case, F2 will be deferred until
F1 flow offload request arrives. When F1 flow offload request is
received it will have O_DMAC information. Using F1’s O_DMAC, driver
creates an L2 context entry in the hardware as part of offloading F1.
F2 will now use F1’s O_DMAC to get the L2 context id associated with
this O_DMAC and other flow fields that are cached already at the time
of deferring F2 for offloading. F2s that arrive after F1 is offloaded
will be directly programmed and not cached.

Signed-off-by: Venkat Duvvuru <[email protected]>
Reviewed-by: Kishore Padmanabha <[email protected]>
Reviewed-by: Ajit Khaparde <[email protected]>

show more ...