[Click] Question about cooperating elementclasses

[Roman Chertov]

"The last IPv4 address blocks allocated" http://lwn.net/Articles/425919/
Time to move to IPv6 and stop using ARP :)


On Tue, 15 Feb 2011 13:33:47 -0800 Philip Prindeville
<philipp_subx at redfish-solutions.com> wrote

> Thought about this some more, and it's going to be more of a challenge than I
> thought.
> 
> Part of the problem is that the packets get queued up in the ARPTable, and
> not in the ARPQuerier, so if you have multiple ARPQuerier instances using the
> same ARPTable (we do... we're in a threaded/polled environment) then the
> packet loses the association to the ARPQuerier (and the ARPQuerier's output
> ports) when it gets queued.
> 
> For that matter, I'm not sure that ARPQuerier::handle_response() is correct:
> all of the packets get put onto the same queue in the ARPTable, so that when
> the queue gets drained they might not go out on the output ports of the same
> instance of ARPQuerier that the came in on.
> 
> Example:
> 
> o1 :: ...
> o2 :: ...
> at :: ARPTable();
> 
> ... -> a1 :: ARPQuerier(TABLE at) -> o1;
> ... -> a2 :: ARPQuerier(TABLE at) -> o2;
> 
> now let's say that packet p1 comes in on a1, and packet p2 comes in on a2. 
> Both are destined to x.x.x.x.
> 
> Then an ARP response comes back resolving x.x.x.x.
> 
> Both packets will be sent to o1, or o2, depending on whether the answer is
> delivered to a1 or a2...
> 
> So packets might be "switched" from the a1...o1 path to o2, or vice versa.
> 
> Is this a bug?
> 
> Should the queuing (and queue expiration) be happening in the ARPQuerier
> class instead?
> 
> -Philip
> 
> 
> On 2/12/11 11:22 AM, Philip Prindeville wrote:
> > I wanted to make a change to ARPTable which would give it the ability to
> > invoke a hook back to ARPQuerier when it deletes queued up packages, but
> > wasn't sure if there's a clean way to do this.
> >
> > In C, I'd just set a pointer to a callback function, but this isn't C.
> >
> > So what's the best way to do it?  Keep in mind that the ARPTable might have
> > been
> >
> > Also, it's the case that the same ARPTable instance might be shared amongst
> > several ARPQuerier instances (because we're in a multi-core environment with
> > several threads running on the same NIC).
> >
> > Oh, one other question about ARPTable vs. ARPQuerier interactions...  if I
> > have that same situation where I'm running multithreaded, and a response
> > packet gets delivered to one ARPQuerier, thereby updating the ARPTable...
> > will the queued up packets in each instance of the ARPQueriers get updated
> > and unblock the packets?
> >
> > Or are the queued packets actually held by the ARPTable (and therefore in a
> > single place)?
> >
> > Looking at how ARPQuerier::handle_ip() and ARPQuerier::handle_response()
> > interact, it looks like the packets are all held by the ARPTable, and when
> > the queue gets drained, all drained by the same instance... so any affinity
> > of individual packets to threads is lost.
> >
> > Packet *cached_packet;
> > arpt->insert(ipa, ena,&cached_packet);
> >
> > while (cached_packet) {
> >       Packet *next = cached_packet->next();
> >       handle_ip(cached_packet, true);
> >       cached_packet = next;
> > }
> >
> >
> > Correct?
> >
> > Thanks.
> >
> > -Philip
> 
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click