From: Simon Horman <simon.horman@corigine.com>
To: edward.cree@amd.com
Cc: linux-net-drivers@amd.com, davem@davemloft.net, kuba@kernel.org,
pabeni@redhat.com, edumazet@google.com,
Edward Cree <ecree.xilinx@gmail.com>,
netdev@vger.kernel.org, habetsm.xilinx@gmail.com
Subject: Re: [PATCH v2 net-next 3/4] sfc: support TC decap rules matching on enc_ip_tos
Date: Fri, 12 May 2023 11:51:33 +0200 [thread overview]
Message-ID: <ZF4MJaY8/3bC4G5e@corigine.com> (raw)
In-Reply-To: <acc9f66562f7a82b2b033bc3ee3470e580036b81.1683834261.git.ecree.xilinx@gmail.com>
On Thu, May 11, 2023 at 08:47:30PM +0100, edward.cree@amd.com wrote:
> From: Edward Cree <ecree.xilinx@gmail.com>
>
> Allow efx_tc_encap_match entries to include an ip_tos and ip_tos_mask.
> To avoid partially-overlapping Outer Rules (which can lead to undefined
> behaviour in the hardware), store extra "pseudo" entries in our
> encap_match hashtable, which are used to enforce that all Outer Rule
> entries within a given <src_ip,dst_ip,udp_dport> tuple (or IPv6
> equivalent) have the same ip_tos_mask.
> The "direct" encap_match entry takes a reference on the "pseudo",
> allowing it to be destroyed when all "direct" entries using it are
> removed.
> efx_tc_em_pseudo_type is an enum rather than just a bool because in
> future an additional pseudo-type will be added to support Conntrack
> offload.
>
> Signed-off-by: Edward Cree <ecree.xilinx@gmail.com>
...
> @@ -425,12 +469,56 @@ static int efx_tc_flower_record_encap_match(struct efx_nic *efx,
> #endif
> encap->udp_dport = match->value.enc_dport;
> encap->tun_type = type;
> + encap->ip_tos = match->value.enc_ip_tos;
> + encap->ip_tos_mask = match->mask.enc_ip_tos;
> + encap->child_ip_tos_mask = child_ip_tos_mask;
> + encap->type = em_type;
> + encap->pseudo = pseudo;
> old = rhashtable_lookup_get_insert_fast(&efx->tc->encap_match_ht,
> &encap->linkage,
> efx_tc_encap_match_ht_params);
> if (old) {
> /* don't need our new entry */
> kfree(encap);
Hi Ed,
encap is freed here.
> + if (pseudo) /* don't need our new pseudo either */
> + efx_tc_flower_release_encap_match(efx, pseudo);
> + /* check old and new em_types are compatible */
> + switch (old->type) {
> + case EFX_TC_EM_DIRECT:
> + /* old EM is in hardware, so mustn't overlap with a
> + * pseudo, but may be shared with another direct EM
> + */
> + if (em_type == EFX_TC_EM_DIRECT)
> + break;
> + NL_SET_ERR_MSG_MOD(extack, "Pseudo encap match conflicts with existing direct entry");
> + return -EEXIST;
> + case EFX_TC_EM_PSEUDO_MASK:
> + /* old EM is protecting a ToS-qualified filter, so may
> + * only be shared with another pseudo for the same
> + * ToS mask.
> + */
> + if (em_type != EFX_TC_EM_PSEUDO_MASK) {
> + NL_SET_ERR_MSG_FMT_MOD(extack,
> + "%s encap match conflicts with existing pseudo(MASK) entry",
> + encap->type ? "Pseudo" : "Direct");
But dereferenced here.
> + return -EEXIST;
> + }
> + if (child_ip_tos_mask != old->child_ip_tos_mask) {
> + NL_SET_ERR_MSG_FMT_MOD(extack,
> + "Pseudo encap match for TOS mask %#04x conflicts with existing pseudo(MASK) entry for TOS mask %#04x",
> + child_ip_tos_mask,
> + old->child_ip_tos_mask);
> + return -EEXIST;
> + }
> + break;
> + default: /* Unrecognised pseudo-type. Just say no */
> + NL_SET_ERR_MSG_FMT_MOD(extack,
> + "%s encap match conflicts with existing pseudo(%d) entry",
> + encap->type ? "Pseudo" : "Direct",
And here.
> + old->type);
> + return -EEXIST;
> + }
> + /* check old and new tun_types are compatible */
> if (old->tun_type != type) {
> NL_SET_ERR_MSG_FMT_MOD(extack,
> "Egress encap match with conflicting tun_type %u != %u",
...
next prev parent reply other threads:[~2023-05-12 9:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-11 19:47 [PATCH v2 net-next 0/4] sfc: more flexible encap matches on TC decap rules edward.cree
2023-05-11 19:47 ` [PATCH v2 net-next 1/4] sfc: release encap match in efx_tc_flow_free() edward.cree
2023-05-11 19:47 ` [PATCH v2 net-next 2/4] sfc: populate enc_ip_tos matches in MAE outer rules edward.cree
2023-05-11 19:47 ` [PATCH v2 net-next 3/4] sfc: support TC decap rules matching on enc_ip_tos edward.cree
2023-05-12 9:51 ` Simon Horman [this message]
2023-05-12 14:27 ` Edward Cree
2023-05-11 19:47 ` [PATCH v2 net-next 4/4] sfc: support TC decap rules matching on enc_src_port edward.cree
2023-05-12 11:50 ` [PATCH v2 net-next 0/4] sfc: more flexible encap matches on TC decap rules patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZF4MJaY8/3bC4G5e@corigine.com \
--to=simon.horman@corigine.com \
--cc=davem@davemloft.net \
--cc=ecree.xilinx@gmail.com \
--cc=edumazet@google.com \
--cc=edward.cree@amd.com \
--cc=habetsm.xilinx@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-net-drivers@amd.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).