All of lore.kernel.org
 help / color / mirror / Atom feed
From: Edward Cree <ecree@solarflare.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: <davem@davemloft.net>, <netdev@vger.kernel.org>,
	<linux-net-drivers@solarflare.com>, <mhabets@solarflare.com>,
	<mslattery@solarflare.com>
Subject: Re: [PATCH net-next] efx: convert to new udp_tunnel infrastructure
Date: Tue, 21 Jul 2020 13:05:39 +0100	[thread overview]
Message-ID: <ecc09a90-1946-fc6a-a5fd-5e0dfe11532d@solarflare.com> (raw)
In-Reply-To: <20200720102156.717e3e68@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

On 20/07/2020 18:21, Jakub Kicinski wrote:
> On Mon, 20 Jul 2020 12:45:54 +0100 Edward Cree wrote:
>> I think I'd prefer to keep the switch() that explicitlychecks
>>  for UDP_TUNNEL_TYPE_GENEVE; even though the infrastructure
>>  makes sure it won't ever not be, I'd still feel more comfortable
>>  that way.  But it's up to you.
> 
> To me the motivation of expressing capabilities is for the core 
> to be able to do the necessary checking (and make more intelligent
> decisions). All the drivers I've converted make the assumption they
> won't see tunnel types they don't support.

Like I say, up to you.  It's not how I'd write it but if that's how
 you're doing all the drivers then consistency is probably good.

>> Could we not keep a 'valid'/'used' flag in the table, used in
>>  roughly the same way we were checking count != 0?
> 
> How about we do the !port check in efx_ef10_udp_tnl_has_port()?
> 
> Per-entry valid / used flag seems a little wasteful.
> 
> Another option is to have a reserved tunnel type for invalid / unused.

Reserved tunnel type seems best to me.  (sfc generally uses all-ones
 values for reserved, so this would be 0xffff.)

Alternatively you could change it to store an enum efx_encap_type in
 the table (see filter.h), and move the conversion to MCDI values to
 efx_ef10_set_udp_tnl_ports(), since that has a defined NONE value.
 But that means converting twice (from udp_parseable_tunnel_type to
 efx_encap_type and then again to MCDI) which isn't the prettiest.

-ed

  reply	other threads:[~2020-07-21 12:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-17 23:53 [PATCH net-next] efx: convert to new udp_tunnel infrastructure Jakub Kicinski
2020-07-18  1:34 ` David Miller
2020-07-20 11:45 ` Edward Cree
2020-07-20 17:21   ` Jakub Kicinski
2020-07-21 12:05     ` Edward Cree [this message]
2020-07-21 19:48       ` Jakub Kicinski
2020-07-22 10:31         ` Edward Cree

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=ecc09a90-1946-fc6a-a5fd-5e0dfe11532d@solarflare.com \
    --to=ecree@solarflare.com \
    --cc=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --cc=linux-net-drivers@solarflare.com \
    --cc=mhabets@solarflare.com \
    --cc=mslattery@solarflare.com \
    --cc=netdev@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.