<div dir="ltr">Understood and agreed. I suspected there would be circuit-state to maintain. As you say, concurrent cells on the same circuit should be queued or thread-locked. I suspect thread-locking will be simple enough - the best approach.<div><br></div><div>And given it's only a problem for the biggest nodes, a design should be chosen that is efficient and focuses on achieving the goals of such users.</div><div><br></div><div>I believe this is that efficient and focused design.</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, 10 Jan 2019 at 00:54, Ian Goldberg <<a href="mailto:iang@cs.uwaterloo.ca">iang@cs.uwaterloo.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Jan 09, 2019 at 08:17:15AM -0500, Ian Goldberg wrote:<br>
> On Wed, Jan 09, 2019 at 08:42:18PM +1100, Todd Hubers wrote:<br>
> > There are early plans to distribute crypto operations across multiple cores<br>
> > [<a href="https://trac.torproject.org/projects/tor/ticket/1749" rel="noreferrer" target="_blank">https://trac.torproject.org/projects/tor/ticket/1749</a>], but there might be<br>
> > a better way.<br>
> > <br>
> > (I registered, but I couldn't find a way to annotate the ticket, so I'm<br>
> > emailing for now)<br>
> > <br>
> > The ticket states the reason being to saturate the bandwidth available (by<br>
> > using all the cores as efficiently as possible).<br>
> > <br>
> > I don't understand why a relay needs to have a "main thread". Network<br>
> > traffic arrives as an async operation and can be sent back out<br>
> > asynchronously. So a final strategy shouldn't have a central thread. The<br>
> > main thread might still be needed for startup, runtime adjustment, and<br>
> > system upkeep, but not for the core network-crypto processing; that should<br>
> > never need to touch the main thread.<br>
> > <br>
> > The current proposal speaks about multi-threading crypto operations, let's<br>
> > call that "A) Speed - Speeding up processing of a single cell". Instead, I<br>
> > propose "B) Concurrency - Restructuring so multiple cells can be processed<br>
> > concurrently".<br>
> > <br>
> > A cell of data should arrive via IO-Completion thread on a random CPU core,<br>
> > have crypto transformation applied on the same one core, then be dispatched<br>
> > onward out via the network. This seems to be quite a simple approach where<br>
> > I would think crypto code can remain the same "single-threaded"<br>
> > implementation.<br>
> > <br>
> > Approach [A] will have diminishing returns as the number of cores<br>
> > increases. You can only break up a cell unit of work so much until you're<br>
> > encrypting one byte per cpu core. However, with approach [B], if you have<br>
> > millions of CPU cores (as an extreme) you can be processing millions of<br>
> > cells concurrently. Therefore, I believe approach [B] would be more<br>
> > scalable.<br>
> > <br>
> > What do you think?<br>
> <br>
> You'll have troubles if cells *on the same circuit* try to be processed<br>
> in parallel on different cores, at least with the current circuit-level<br>
> crypto.  But, once circuits are established, handing each circuit to a<br>
> different thread/core (or more clever worker structure) is something<br>
> that I think at least boradly makes sense, and indeed I have been<br>
> proposing to have my students work on.<br>
<br>
(Of course, this only is even relevant for the very highest-bandwidth<br>
nodes; my own node, for example, running on 5-year-old hardware with no<br>
special configuration, was pushing 400 Mbps last month, with one core<br>
at 80%, one at 11%, one at 6%, and the rest trivially small.)<br>
-- <br>
Ian Goldberg<br>
Professor and University Research Chair<br>
Cheriton School of Computer Science<br>
University of Waterloo<br>
_______________________________________________<br>
tor-dev mailing list<br>
<a href="mailto:tor-dev@lists.torproject.org" target="_blank">tor-dev@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev" rel="noreferrer" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><span style="font-size:small">--</span></div><div><span style="font-size:small">Todd Hubers</span><br></div></div></div></div></div>