[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200619094156.31184-1-satish.d@oneconvergence.com>
Date: Fri, 19 Jun 2020 15:11:53 +0530
From: dsatish <satish.d@...convergence.com>
To: davem@...emloft.net
Cc: jhs@...atatu.com, xiyou.wangcong@...il.com, jiri@...nulli.us,
kuba@...nel.org, netdev@...r.kernel.org,
simon.horman@...ronome.com, kesavac@...il.com,
satish.d@...convergence.com, prathibha.nagooru@...convergence.com,
intiyaz.basha@...convergence.com, jai.rana@...convergence.com
Subject: [PATCH net-next 0/3] cls_flower: Offload unmasked key
This series of patches add support for offloading unmasked key along
with the masked key to the hardware. This enables hardware to manage
its own tables better based on the hardware features/capabilities.
It is possible that hardware as part of its limitations/optimizations
remove certain flows. To handle such cases where the hardware lost
the flows, tc can offload to hardware if it receives a flow for
which there exists an entry in its flow table. To handle such cases
TC when it returns EEXIST error, also programs the flow in hardware,
if hardware offload is enabled.
This also covers the uses case where addr_type type should be set
only if mask for ipv4/v6 is non-zero, as while classifying packet,
address type is set based on mask dissector of IPv4 and IPV6 keys,
hence while inserting flow also addr type should be set based on
the mask availability.
Satish Dhote (3):
cls_flower: Set addr_type when ip mask is non-zero
cls_flower: Pass the unmasked key to the hardware
cls_flower: Allow flow offloading though masked key exist.
include/net/flow_offload.h | 45 ++++++++++
net/core/flow_offload.c | 171 +++++++++++++++++++++++++++++++++++++
net/sched/cls_flower.c | 132 +++++++++++++++++++++-------
3 files changed, 316 insertions(+), 32 deletions(-)
--
2.17.1
Powered by blists - more mailing lists