prop224: Optimize hsdir_index calculation

Let's include hsdir_index_t in the node_t instead of a pointer that we allocate, since that structure is always present anyway.

See here for more details: https://oniongit.eu/dgoulet/tor/merge_requests/6#note_412

changed milestone to %Tor: 0.3.4.x-final

added 032-unreached component::core tor/tor milestone::Tor: 0.3.4.x-final owner::neel points::1 priority::medium prop224 prop224-extra resolution::implemented severity::normal status::closed tor-hs type::enhancement labels

Trac:
Parent: #20657 (moved) to N/A

Trac:
Summary: prop224: Include hsdir_index in node_t instead of pointer to prop224: Optimize hsdir_index calculation

After our #23387 (moved) refactoring of hsdir index logic Nick suggested that we don't need to keep all 3 around in memory, since two of them are always identical: https://oniongit.eu/asn/tor/merge_requests/6#note_1201

Mark a large number of tickets that I do not think we will do for 0.3.2.

Trac:
Milestone: Tor: 0.3.2.x-final to Tor: unspecified
Keywords: N/A deleted, 032-unreached added

Trac:
Owner: N/A to neel
Cc: N/A to neel@neelc.org
Status: new to assigned

Trac:
b23094-r001.patch

Patch (Revision 1)

I have a patch for this. The filename is b23094-r001.patch.

Seems ok to me, but someone should turn it into a GitHub branch and run it through Travis CI before it is merged.

Neel, if you would like to run your branches through Travis CI, here is how to set it up: https://trac.torproject.org/projects/tor/ticket/23883#comment:3

Trac:
Status: assigned to needs_review
Milestone: Tor: unspecified to Tor: 0.3.4.x-final
Type: defect to enhancement

Travis CI for this patch is: https://travis-ci.org/neelchauhan/tor/builds/372561294

It seems to have all passed.

Replying to asn:

Let's include hsdir_index_t in the node_t instead of a pointer that we allocate, since that structure is always present anyway.

See here for more details: https://oniongit.eu/dgoulet/tor/merge_requests/6#note_412

This is implemented in https://github.com/neelchauhan/tor/tree/b23094 and is ready to merge.

Replying to asn:

After our #23387 (moved) refactoring of hsdir index logic Nick suggested that we don't need to keep all 3 around in memory, since two of them are always identical: https://oniongit.eu/asn/tor/merge_requests/6#note_1201

Removing hsdir_index_t.fetch is not implemented. We need to:

• analyse the state machine of fetch, store_first, and store_second to make sure that fetch is always equal to store_first or store_second
• work out the condition that we can use to select betweeen store_first or store_second when we want fetch
• write a function that produces fetch from a hsdir_index_t, and use it instead of fetch

We can do this in a separate ticket if you'd like to merge just the first patch. They are independent. And integers are cheap.

Trac:
Status: needs_review to merge_ready

Replying to teor:

We can do this in a separate ticket if you'd like to merge just the first patch. They are independent. And integers are cheap.

I think think we should just merge.

Ok, I opened #24964 (moved) for the remaining work.

Merged this to master; thanks!

Trac:
Resolution: N/A to implemented
Status: merge_ready to closed

closed

changed time estimate to 8h

mentioned in issue #25964 (moved)

moved to tpo/core/tor#23094 (closed)

mentioned in issue tpo/core/tor#25964 (closed)