Netdev Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Justin Iurman <justin.iurman@uliege.be>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net, kuba@kernel.org,
	yoshfuji@linux-ipv6.org, dsahern@kernel.org, tom@herbertland.com
Subject: Re: [RFC net-next] ipv6: Attempt to improve options code parsing
Date: Tue, 3 Aug 2021 18:06:33 +0200 (CEST)	[thread overview]
Message-ID: <989297896.30838930.1628006793490.JavaMail.zimbra@uliege.be> (raw)
In-Reply-To: <ce46ace3-11b9-6a75-b665-cee79252550e@gmail.com>

>> As per Eric's comment on a previous patchset that was adding a new HopbyHop
>> option, i.e. why should a new option appear before or after existing ones in the
>> list, here is an attempt to suppress such competition. It also improves the
>> efficiency and fasten the process of matching a Hbh or Dst option, which is
>> probably something we want regarding the list of new options that could quickly
>> grow in the future.
>> 
>> Basically, the two "lists" of options (Hbh and Dst) are replaced by two arrays.
>> Each array has a size of 256 (for each code point). Each code point points to a
>> function to process its specific option.
>> 
>> Thoughts?
>> 
> Hi Justin
> 
> I think this still suffers from indirect call costs (CONFIG_RETPOLINE=y),
> and eventually use more dcache.

Agree with both. It was the compromise for such a solution, unfortunately.

> Since we only deal with two sets/arrays, I would simply get rid of them
> and inline the code using two switch() clauses.

Indeed, this is the more efficient. However, we still have two "issues":
 - ip6_parse_tlv will keep growing and code could look ugly at some point
 - there is still a "competition" between options, i.e. "I want to be at the top of the list"

Anyway, your solution is better than the current one so it's probably the way to go right now.

  reply	other threads:[~2021-08-03 16:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-02 20:51 Justin Iurman
2021-08-03 15:03 ` Eric Dumazet
2021-08-03 16:06   ` Justin Iurman [this message]
2021-08-03 16:35     ` Eric Dumazet
2021-08-03 17:41       ` Justin Iurman

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=989297896.30838930.1628006793490.JavaMail.zimbra@uliege.be \
    --to=justin.iurman@uliege.be \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=eric.dumazet@gmail.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=tom@herbertland.com \
    --cc=yoshfuji@linux-ipv6.org \
    --subject='Re: [RFC net-next] ipv6: Attempt to improve options code parsing' \
    /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

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).