ip tagging: level compressed trie implementation by ccaraman · Pull Request #2351 · envoyproxy/envoy

ccaraman · 2018-01-11T21:34:02Z

Implementation of the Level Compressed Trie as described by the paper IP address lookup using LC-tries by Stefan Nelson and Gunnar Karlsson.

For this implementation, I referenced https://github.com/beevek/libkrb/blob/master/krb/lc_trie.hpp which is based off of the C implementation found at http://www.csc.kth.se/~snilsson/software/router/C/

Note: This doesn't support nested prefixes. I've added a TODO to add support in the next PR.

Risk Level: Medium - This will be the core logic behind the Ip Tagging Filter.

Testing: Unit Tests. A todo has been added for performance benchmark.

Docs Changes: Docs will be updated when the filter consumes this implementation.
Release Notes: I'll update the release notes when the filter consumes this implementation.

Related to #1001

Next Pr's will do the following:

Consume the LC-Trie in the Ip Tagging filter and update the IP Tagging filter to consume V2.
Add Prefix support
Performance benchmark testing.

Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>

mattklein123 · 2018-01-11T22:16:31Z

@ccaraman do you mind just marking down the notes we just went over so they don't get duplicated by other reviewers? Awesome stuff!

Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>

ccaraman · 2018-01-12T01:03:15Z

+      // avoid resizing while building the trie.
+      // TODO(ccaraman): Define a better buffer value for the trie_ size.
+      // TODO(ccaraman): Define a better buffer value for the trie_ size.
+      // The value(2000000) was used in the original implementation in


@brian-pane Do you have any insight as to why 2000000 was chosen? Is there a better way to compute a buffer given the fill_factor?

In the original implementation, I think the author just picked 2000000 as a really big number that they thought would be big enough to handle any situation. And then, after populating the buffer, they resized it down to the amount of space they actually ended up using.

I don't have a good way to compute the buffer size in advance, since it depends on the exact shape of the tree. However, I think it's okay to not pre-size the buffer. I think std::vector uses a power-of-two allocator internally, so the number of resize operations will be O(log(N)) for N prefixes. So my proposal is to just use std::vector, see how fast it is, and then optimize if needed.

That sounds good! I prefer your suggestion. I'll change the comment to say how this diverged from the reference implementation.

I decided to not remove the resizing due to the accessing pattern used across the code base. Once there are performance benchmark tests, the resizing the vector can be something we look to improve if needed.

Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>

ccaraman · 2018-01-12T01:07:24Z

@junr03 Please take a first pass.

brian-pane · 2018-01-12T01:36:03Z

+private:
+  /**
+   * Extract n bits from input starting at position p.
+   * @param position supplies the position.


It's called position in the comment but p in the declaration.

brian-pane · 2018-01-12T01:37:04Z

+   * Extract n bits from input starting at position p.
+   * @param position supplies the position.
+   * @param n supplies the number of bits to extract.
+   * @param input supplies the


... "IP address from which to extract the bits," maybe?

Thank you for catching that. I'll update.

brian-pane · 2018-01-12T01:41:23Z

+    // The IP's are stored in network byte order. By shifting the value to the left by p bits, the
+    // bits between 0 and p-1 are zero'd out. Then to get the n bits, shift the IP back by the
+    // address_size minus the number of desired bits.
+    return input << p >> (address_size - n);


I think this may be unsafe. C doesn't specify whether a right shift is logical (high order bits get filled with zeros) or arithmetic (high order bits get filled with a copy of whatever the input high order bit was).

It's probably safest to bitwise-and the result of these shifts with a mask consisting of n ones in the low order bits.

I double checked the c++ standard and for unsigned left/right shifting is safe and produces the values we expect. In this version of the pr, they were int's. I've change the methods to be uint32_t.

brian-pane · 2018-01-12T01:45:59Z

+    return input << n >> n;
+  }
+
+  template <class IpType, uint32_t address_size = 8 * sizeof(IpType)> struct IpPrefixes {


Should this struct be named "IpPrefix," singular, since it holds just one prefix?

Yes, that is clearer. I've updated it to be IpPrefix.

brian-pane · 2018-01-12T01:50:35Z

+     * http://www.csc.kth.se/~snilsson/software/router/C/
+     *
+     * Note: This trie handles Ipv4 and Ipv6 separately.
+     * Note: The trie can only support up 524288(2^19) nodes. Please see LcNode for further


Would you be open to making this unlimited? The global routing table currently contains 700,000 prefixes, so it won't fit within the 2^19 limit. I know Envoy itself is unlikely to ever have that many prefixes configured; but if this implementation can support more nodes, it could be useful to people working on other projects someday.

I should note, though, that making this unlimited would require using a uint64_t instead of uint32_t for LcNode, so the LC trie would take up more cache space.

I'm am open to it. I don't think we need it now. I've added a comment to change the data structure for LcNode to be uint64_t if any consumer requires it.

To summarize our offline conversation, the code will stay with uint32_t as the underlying LcNode structure.

To avoid getting an out of range exception, I'll add a check at the beginning of every buildRecursive call to ensure the size is > the position being accessed in the Lc-Trie that way if the number of trie_ nodes required is greater than 2^20 the code will throw an exception. If this case is it, then the uint64_t conversation should be revisited.

Once there are larger data sets and perf tests, there can be an effort to see if using uint64_t is worth supporting larger set of prefixes. Another benefit is then there can be some experimentation in determining what the buffer can be.

brian-pane · 2018-01-12T02:02:43Z

+     *
+     * The LcNode has three parts to it
+     * - Branch: the first 5 bits represent the branching factor. This supports a branching factor
+     * of 2^31.


The max branching factor is just 31 rather than 2^31, right?

Yes, that is another typo (and compression of the logic 2^5-1 = 31).

brian-pane · 2018-01-12T02:04:02Z

+     * of 2^31.
+     * - Skip: the next 7 bits represent the number of bits to skip when looking at an IP address.
+     * This value can be between 0 and 127, so IPv6 is supported as well.
+     * - Address: the remaining 30 bits represent the pointer. If branch value is not zero, this


If I'm counting right, it seems like there are only 20 remaining bits. 32 bits minus 5 for the branching factor, minus 7 for the skip count.

Yes, that is a typo. I'll fix that.

brian-pane · 2018-01-12T02:09:48Z

+    /**
+     * @return Returns the value at bits 6-12.
+     */
+    static LcNode getSkip(LcNode node) { return node >> 20 & 127; }


In order to make code like this less error-prone, the mechanism I usually use is:

struct LcNode { uint32_t branch:5; uint32_t skip:7; uint32_t address:20; };

Then you can just refer to fields in the struct by name, and let the compiler deal with all the bit shifting.

I don't know if bitfield structs like that are encouraged or discouraged in Envoy, though.

this is fine, SGTM.

Thank you for the suggestion. This is cleaner. I've updated the code to use your proposed structure.

brian-pane · 2018-01-12T02:32:34Z

+      }
+
+      // The node used for the trie uses the last 20 bits of uint32_t. The trie cannot support
+      // an input greater than 524288(2^19) nodes.


I think it might be possible for a trie built from 2^19 prefixes to end up with more than 2^20 nodes, if the fill_factor is set to something less than 0.5. Hmmm, maybe the safe limit is 2^20 * fill_factor, but I haven't thought through it fully, so please don't take my word for it. :)

brian-pane · 2018-01-12T02:36:38Z

+      std::sort(tag_data.begin(), tag_data.end());
+      ip_prefixes_.push_back(tag_data[0]);
+
+      // Remove duplicate entries and nested prefixes.


Does the original LC trie code work with nested prefixes? I know the corresponding paper didn't use any nested prefixes in its examples, but it isn't clear to me if the design can handle nested prefixes without modifications.

I'll update the comment here and for the class and method definition. Currently, the code will throw an exception if there are nested prefixes. I have a todo to make the exception show which prefixes are nested.

The future implementation for nested prefixes won't modify the algorithm or the underlying LcNode. There are two options to handle it:

Have a sorted list of the nested prefixes

Use another lc-trie for the nested prefixes
The most general prefix will have a way of accessing one of those options once it is implemented.

FWIW, I would do the implementation that was done in the original C implementation. IMO it's very easy to understand and will perform very well (linked list of prefixes, accessed from trie node). It will also perform well for our case where 0 prefixes will be by far the most common case and 1 prefix will be the next most common case by a huge margin.

brian-pane · 2018-01-12T02:48:15Z

+  EXPECT_EQ("", trie.search(Utility::parseInternetAddress("1.2.3.4")));
+}
+
+TEST(LcTrie, BothIpvVersions) {


In practice, will IPv4 and IPv6 need separate trees? I'm thinking about the case where a user has configured an IPv4 prefix with length 24, and then they get a request from an IPv6 address whose first 24 bits happen to match the prefix. In that scenario, the user will probably want the IPv6 address to not match the IPv4 prefix.

Oops, never mind; I just realized the LCTrie maintains two separate LCTrieInternal objects, so it won't accidentally match v6 addresses against v4 prefixes.

I'll improve the comments for the LcTrie to make this clearer. Thank you for the feedback.

brian-pane · 2018-01-12T03:12:25Z

Thanks for implementing this!

In case it's useful for unit tests, I computed the IPv4 CIDR prefixes corresponding to the examples in the original paper. These prefixes probably don't exercise 100% of the trie-building code paths, but they do result in a trie with a mix of different branching factors (figure 3 from the paper).

0.0.0.0/4
16.0.0.0/4
40.0.0.0/5
64.0.0.0/3
96.0.0.0/4
112.0.0.0/4
128.0.0.0/3
160.0.0.0/6
164.0.0.0/6
168.0.0.0/5
176.0.0.0/5
184.0.0.0/5
192.0.0.0/3
232.0.0.0/8
233.0.0.0/8

mattklein123 · 2018-01-12T16:41:10Z

+  ipv6_trie_.reset(new LcTrieInternal<Ipv6>(ipv6_prefixes, fill_factor, root_branching_factor));
+}
+
+std::string LcTrie::search(Network::Address::InstanceConstSharedPtr ip_address) const {


drive by quick comment: const Network::Address::Instance&.

Will let you get through @brian-pane and @junr03 reviews before looking more in-depth. Looks great though!

brian-pane · 2018-01-12T18:43:15Z

+        }
+
+        if (k == 0) {
+          if (p == first + n) {


Do the unit tests currently cover both this and its "else" case? I ask because the handling of the "k==0" situation (which requires interpolating the values for new child nodes that have to be created when the number of children for a node is less than 2^branch_) seems like one of the trickiest parts of the LC Trie construction.

I double checked. The sample input provided in the paper covers all of the if/else cases in buildRecursive.

ccaraman · 2018-01-12T23:00:50Z

+
+// TODO(ccaraman): Add a performance benchmark test.
+
+TEST(LcTrie, Ipv4) {


I'm going to restructure these tests. There is lots of duplicate in logic, take in a list of strings for cidr range, build trie, search for an input.

Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>

ccaraman · 2018-01-16T23:39:27Z

+
+      uint32_t address = next_free_index;
+      trie_[position].branch_ = output.branch_;
+      trie_[position].skip_ = output.prefix_ - prefix;


Synced with Jose offline - i'll add a comment that the skip value is the number of bits between the last prefix at prefix and the output.prefix . (Mention that it is the number of bits)

ccaraman · 2018-01-16T23:43:19Z

+      ComputePair(int branch, int prefix) : branch_(branch), prefix_(prefix) {}
+
+      uint32_t branch_;
+      uint32_t prefix_;


I'll add note that this is total number of bits that have the same prefix for a range of data.

junr03

I have more comments but I have to leave for now. Will put out more tonight

junr03 · 2018-01-16T19:56:40Z

+   * supported.
+   * @param  ip_address supplies the IP address.
+   * @return tag from the CIDR range that contains 'ip_address'. An empty string is returned
+   *             if no prefix contains 'ip_address'or there is no data for the IP version of the


nit: space between 'ip_address'or

junr03 · 2018-01-16T20:04:52Z

+   *              byte order.
+   * @return extracted bits in the format of IpType.
+   */
+  template <class IpType, uint32_t address_size = 8 * sizeof(IpType)>


can we make the number of bits in a byte a constant?

I was curious, so I just looked it up, and there's standardized CHAR_BIT in C and C++. (Documentation)

junr03 · 2018-01-16T21:41:23Z

+   * @param tag_data supplies a vector of tag and CIDR ranges.
+   * @param fill_factor supplies the fraction of completeness to use when calculating the branch
+   *                    value for a sub-trie.
+   * @param root_branching_factor supplies the branching factor at the root. The paper suggests for


I know the paper is below. But it might be useful to cite the paper up top and let the reader know from the beginning that this is based on the paper?

junr03 · 2018-01-16T21:42:06Z

+   * 'http://www.csc.kth.se/~snilsson/software/router/C/' were used as reference during
+   * implementation.
+   *
+   * Note: The trie can only support up 524288(2^19) nodes.


Might be worth it to spell out why. Reference the comment in the build method?

junr03 · 2018-01-16T21:56:48Z

+      // In theory, the trie_ should only need twice the amount of entries of CIDR ranges.
+      // To prevent index out of bounds issues, only support a maximum of 2^19 CIDR ranges.
+      // TODO(ccaraman): Add a test case for this.
+      if (tag_data.size() > (1 << 19)) {


Make a constant of the supported size

junr03 · 2018-01-16T22:02:58Z

+              tag_data[i].asString(), tag_data[i - 1].asString()));
+        }
+
+        if (tag_data[i - 1].compare(tag_data[i]) != 0) {


overload ==?

junr03 · 2018-01-16T22:14:53Z

+    /**
+     * Recursively build a trie for IP prefixes from position 'first' to 'first+n-1'.
+     * @param prefix supplies the prefix to ignore when building the sub-trie.
+     * @param first supplies the ip_prefixes_ index into for this sub-trie.


junr03 · 2018-01-16T22:35:27Z

+      }
+
+      // Compute the number of bits required for branching by checking for all
+      // patterns (b=2 {00, 01, 10, 11}; b=3 {000,001,010,011,100,101,110,111}, etc)


this comment doesnt flow

compute the number of bits required for branching by checking for all patterns are covered in the set?

junr03 · 2018-01-16T23:12:28Z

+      uint32_t address_ : 20;
+    };
+
+    // Vector that contains the CIDR ranges and tags.


explain that this is kept because you need to make sure that you've got a match. I know this is based on the paper, but it might be worth it to spell that here.

junr03 · 2018-01-16T23:45:12Z

+     * @param n supplies the number of nodes to use while computing the branch.
+     * @return pair of integers for the branching factor and the skip.
+     */
+    ComputePair computeBranch(uint32_t prefix, uint32_t first, uint32_t n) const {


I would rename this method. computeBranchAndSkip?

Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>

junr03

some more comments

junr03 · 2018-01-17T20:00:15Z

+        // Stop iterating once the size of the branch (with the fill factor ratio) is able to
+        // contain all of the prefixes within the current range of ip_prefixes_[first] to
+        // ip_prefixes_[first+n-1].
+      } while (count >= fill_factor_ * (1 << branch));


I am a little concerned about the default fill factor of 0. That would mean that any count would keep increasing the branch going up and collapsing the trie

fill factor will be validated in the config to have this range (0, 1]

junr03 · 2018-01-17T20:11:40Z

+      } while (count >= fill_factor_ * (1 << branch));
+
+      // Set the branching factor.
+      compute.branch_ = branch - 1;


comment on the -1

junr03 · 2018-01-17T20:13:20Z

+        // exception be thrown.
+        // TODO(ccaraman): Add a test case.
+        if (position > MAXIMUM_TRIE_NODES) {
+          throw EnvoyException(fmt::format("The number of internal nodes required for the LC-Trie "


I know this is not the responsibility of the throwing code. But given we own both the throwing code and the code that receives the exception, I want to make sure this is caught at config time, which I am 99% sure it does.

Yes, this will get thrown during config parsing The call chain is LcTrie()->LcTrieInternal<>-> build()->buildRecursive

junr03 · 2018-01-17T20:16:51Z

+      for (uint32_t bit_pattern = 0; bit_pattern < static_cast<uint32_t>(1 << output.branch_);
+           ++bit_pattern) {
+
+        // count is the number of entries in the base vector that have the same bit pattern as the


s/base/ip_prefixes_

junr03 · 2018-01-17T20:19:31Z

+        }
+
+        // This logic was taken from
+        // https://github.com/beevek/libkrb/blob/24a224d3ea840e2e7d2926e17d8849aefecc1101/krb/lc_trie.hpp#L396.


I think this section lacks in explanation compared to the rest of the code, and it is a pretty crucial set of operations. I'll leave it up to you if you want to spell it out more. At the very least to explain what each case is.

Added more comments

Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>

mattklein123

Looks great! Just a few comments.

mattklein123 · 2018-01-18T21:04:37Z

+ * within this class with no calling pattern changes.
+ *
+ * The algorithm to build the LC-Trie is desribed in the paper 'IP-address lookup using LC-tries'
+ * by'S. Nilsson' and 'G. Karlsson'. Refer to LcTrieInternal for implementation and algorithm


nit: missing space after "by". Please also provide direct link to paper/article if possible.

Fixed. Found a free version of the paper hosted by the author.

mattklein123 · 2018-01-18T21:05:16Z

+   *                              factor. It reduces the depth of the trie.
+   */
+  LcTrie(const std::vector<std::pair<std::string, std::vector<Address::CidrRange>>>& tag_data,
+         double fill_factor = 0.5, uint32_t root_branching_factor = 0);


Should we just make the default 16 for root_branching_factor?

I think it may be better to use a much smaller default, like 6 or 8. Or maybe auto-compute the root branching factor based on the number of prefixes submitted to the build function.

Here's my rationale...

With a root_branching factor of 16, each trie will use at least 256KB of memory: 2^16 nodes at the first level below the root, times 4 bytes per node.

When Nilsson et al recommended 16 bits of branching at the root in their original paper, their target use case was a router with at least tens of thousands of prefixes. In that scenario, dedicating 256KB of memory to shard the trie into 2^16 buckets seems like a reasonable tradeoff of memory for speed.

But proxy applications, if my own experience is representative, will usually have a much smaller number of prefixes configured: often dozens of prefixes, sometimes hundreds, rarely tens of thousands. For such configurations, 256KB strikes me as too much overhead, especially relative to the L1D and even L2 cache sizes of contemporary server CPUs.

SGTM. Whatever you all think is best. Was mostly just wondering if the default should not be 0.

I'll leave it at zero for now.

mattklein123 · 2018-01-18T21:08:55Z

+  // Helper methods to retrieve the string representation of the address in IpPrefix using
+  // inet_ntop. These strings are used in the nested prefixes exception messages.
+  // TODO(ccaraman): Remove once nested prefixes are supported.
+  static std::string toString(const Ipv4& input) {


For these can you just construct an Ipv4Instance or Ipv6Instance and return the string from that? Seems simpler.

Good idea. Fixed.

mattklein123 · 2018-01-18T21:11:08Z

+        }
+      }
+
+      // In theory, the trie_ vector can have at most twice the number of  ip_prefixes entries - 1.


nit: extra space before ip_prefixes

mattklein123 · 2018-01-18T21:13:57Z

+
+  /**
+   * Converts Ipv6 address in std::array<uint8_t, 16> to absl::uint128 in host byte order.
+   * TODO (ccaraman): Remove this workaround once Ipv6Helper returns absl::uint128t.


Can we just do that now? It doesn't seem that hard and seems like it would clean up a bunch of stuff. You could do another PR and just merge that into this?

I'll do this in a separate PR and merge it into here.

Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>

mattklein123

two small nits. Nice work!

mattklein123 · 2018-01-29T20:56:33Z

+   *             if no prefix contains 'ip_address' or there is no data for the IP version of the
+   *             ip_address.
+   */
+  std::string getTag(const Network::Address::InstanceConstSharedPtr ip_address) const;


nit: const Network::Address::InstanceConstSharedPtr&

mattklein123 · 2018-01-29T20:58:31Z

+
+class LcTrieTest : public testing::Test {
+public:
+  LcTrieTest() {}


Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>

Signed-off-by: Piotr Sikora <piotrsikora@google.com>

Signed-off-by: Mike Schore <mike.schore@gmail.com> Signed-off-by: JP Simard <jp@jpsim.com>

ccaraman added 4 commits January 11, 2018 12:19

Lc Trie for Ipv4 and Ipv6.

eed6204

Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>

Merge branch 'master' of github.com:lyft/envoy into lc_trie

f2a4706

Remove local change.

6591aa9

Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>

Remove comments.

2c233b2

Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>

ccaraman added 2 commits January 11, 2018 16:57

More cleanup

6d4ee91

Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>

Fix todo notation.

dc70e2c

Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>

ccaraman commented Jan 12, 2018

View reviewed changes

Fix format

db3ed5e

Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>

brian-pane reviewed Jan 12, 2018

View reviewed changes

mattklein123 reviewed Jan 12, 2018

View reviewed changes

mattklein123 assigned junr03 Jan 12, 2018

brian-pane reviewed Jan 12, 2018

View reviewed changes

ccaraman commented Jan 12, 2018

View reviewed changes

mattklein123 assigned brian-pane Jan 13, 2018

ccaraman added 3 commits January 14, 2018 04:21

Address pr comments.

3994dc2

Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>

Clean up comments.

798a93f

Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>

Fix format.

aad18a5

Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>

ccaraman added 4 commits January 15, 2018 22:51

Silly typo.

cc03a1b

Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>

Add assert in bazel.

029f255

Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>

Fix assert.

7e7983d

Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>

The old precommit hook doesn't exist anymore. :(

4158e96

Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>

ccaraman changed the title ~~WIP - ip tagging: level compressed trie implementation~~ ip tagging: level compressed trie implementation Jan 16, 2018

ccaraman commented Jan 16, 2018

View reviewed changes

junr03 reviewed Jan 17, 2018

View reviewed changes

Address comments.

5af6aac

Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>

junr03 reviewed Jan 17, 2018

View reviewed changes

ccaraman added 2 commits January 17, 2018 14:43

Address more comments.

7856b0d

Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>

Branch comment

19dda7e

Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>

mattklein123 reviewed Jan 18, 2018

View reviewed changes

ccaraman added 4 commits January 26, 2018 12:54

Merge branch 'master' into lc_trie

e166972

Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>

Address last set of comments.

b100fbe

Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>

Remove extra line.

43518ed

Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>

Remove extra char.

c413735

Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>

mattklein123 reviewed Jan 29, 2018

View reviewed changes

Don't forget the reference.

3b7711b

Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>

mattklein123 approved these changes Jan 29, 2018

View reviewed changes

ccaraman merged commit f6be236 into master Jan 29, 2018

ccaraman deleted the lc_trie branch January 29, 2018 23:14

Shikugawa pushed a commit to Shikugawa/envoy that referenced this pull request Mar 28, 2020

Fix previous commit. (envoyproxy#2351)

6bf6aa2

Signed-off-by: Piotr Sikora <piotrsikora@google.com>

jpsim pushed a commit that referenced this pull request Nov 28, 2022

cleanup: consistently use nullptr in cc contexts (#2351)

e49fb58

Signed-off-by: Mike Schore <mike.schore@gmail.com> Signed-off-by: JP Simard <jp@jpsim.com>

jpsim pushed a commit that referenced this pull request Nov 29, 2022

cleanup: consistently use nullptr in cc contexts (#2351)

3197e18

Signed-off-by: Mike Schore <mike.schore@gmail.com> Signed-off-by: JP Simard <jp@jpsim.com>


		// TODO(ccaraman): Add a performance benchmark test.

		TEST(LcTrie, Ipv4) {

Conversation

ccaraman commented Jan 11, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mattklein123 commented Jan 11, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ccaraman Jan 12, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ccaraman commented Jan 12, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

brian-pane Jan 12, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

brian-pane Jan 12, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

brian-pane commented Jan 12, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ccaraman commented Jan 11, 2018 •

edited

Loading

ccaraman Jan 12, 2018 •

edited

Loading

brian-pane Jan 12, 2018 •

edited

Loading

brian-pane Jan 12, 2018 •

edited

Loading