[Click] click Digest, Vol 92, Issue 25
Justok Jiang|蒋小可
justok06 at gmail.com
Tue Feb 22 01:54:03 EST 2011
Dear all,
I am sure If I could send email to this mailling-list when I have some Questions about Click.
If It's not appropriate, Please skip this email; but I would be thanksful if some do me some favor to answer.
Q. 1/
FromDevice(eth1)->
c::Classifier(12/0806 20/0001,
12/0806 20/0002,
12/0800,
-);
I would find that all the packet are sent to c[3]
FromDevice(eth1)->Strip(14)->cip::CheckIPHeader->IPClassifier->IPPrint(ip)->Discard;
cip[1]->Discard;
I would find that some IP packet also output warning msg "cip: IP header check failed: bad IP version "
Q. 2/
My Project is flexable, so I want to use some configure files, which store host name, host interface and their ip.
So how can I use that configure file?
Q. 3/
About script,
s :: Script(set x 0,
label begin_loop,
print $x,
set x $(s.add $x 1),
goto begin_loop $(s.lt $x 5),
);
this code runs well and output "0 1 2 3 4", but
s :: Script(set x 0,
label begin_loop,
print $x,
set x $(s.add $x 1),
goto begin_loop $(s.lt $x 5),
);
InfiniteSource(DATA \<00 00 c0 ae 67 ef 00 00 00 00 00 00 08 00
45 00 00 28 00 00 00 00 40 11 77 c3 01 00 00 01
02 00 00 02 13 69 13 69 00 14 d6 41 55 44 50 20
70 61 63 6b 65 74 21 0a>, LIMIT 10, STOP true)
-> Strip(14)
-> Align(4, 0) // in case we're not on x86
-> cih::CheckIPHeader()
->IPPrint(ip)
->c::Counter
->Discard;
those code runs well, but the output have no "0 1 2 3 4"
and
s :: Script(set x 0,
label begin_loop,
print $x,
set x $(s.add $x 1),
goto begin_loop $(s.lt $x 5),
);
//InfiniteSource(DATA \<00 00 c0 ae 67 ef 00 00 00 00 00 00 08 00
//5 00 00 28 00 00 00 00 40 11 77 c3 01 00 00 01
//02 00 00 02 13 69 13 69 00 14 d6 41 55 44 50 20
//70 61 63 6b 65 74 21 0a>, LIMIT 10, STOP true)
// -> Strip(14)
// -> Align(4, 0) // in case we're not on x86
// -> cih::CheckIPHeader()
// ->IPPrint(ip)
// ->c::Counter
// ->Discard;
//
//Idle->Queue->Discard;
FromDevice(eth1)->Strip(14)->Align(4,0)->cih::CheckIPHeader->IPPrint(ip)->Discard;
can works as i expect.
so could anybody tell me why?
2011-02-20
Justok Jiang|蒋小可
发件人： click-request
发送时间： 2011-02-20 01:01:51
收件人： click
抄送：
主题： click Digest, Vol 92, Issue 25
Send click mailing list submissions to
click at amsterdam.lcs.mit.edu
To subscribe or unsubscribe via the World Wide Web, visit
https://amsterdam.lcs.mit.edu/mailman/listinfo/click
or, via email, send a message with subject or body 'help' to
click-request at amsterdam.lcs.mit.edu
You can reach the person managing the list at
click-owner at amsterdam.lcs.mit.edu
When replying, please edit your Subject line so it is more specific
than "Re: Contents of click digest..."
Today's Topics:
1. Re: Question about cooperating elementclasses (Bobby Longpocket)
2. Re: Question about cooperating elementclasses (Philip Prindeville)
----------------------------------------------------------------------
Message: 1
Date: Fri, 18 Feb 2011 15:04:54 -0800 (PST)
From: Bobby Longpocket <bobbylongpocket at yahoo.com>
Subject: Re: [Click] Question about cooperating elementclasses
To: Philip Prindeville <philipp_subx at redfish-solutions.com>, Eddie
Kohler <kohler at cs.ucla.edu>
Cc: click at pdos.csail.mit.edu
Message-ID: <238714.55567.qm at web43133.mail.sp1.yahoo.com>
Content-Type: text/plain; charset=iso-8859-1
I like the idea of moving packet queuing into ARPQuerier proper.
There may be reasons that packets need to stay on the same path whether or not they hit address resolution. If nothing else, it makes packet flow easier to follow.
To make sure the 'right' ARPQuerier is awakened to send pending packets, just use external click logic. If the existing configuration doesn't ensure that the sender of a query will receive the response, then just Tee() the ARP input to all the related ARPQueriers.
I like the idea on a more superficial level because I don't like that something called "ARPTable" has gotten into the packet storage business.
--- On Thu, 2/17/11, Eddie Kohler <kohler at cs.ucla.edu> wrote:
> From: Eddie Kohler <kohler at cs.ucla.edu>
> Subject: Re: [Click] Question about cooperating elementclasses
> To: "Philip Prindeville" <philipp_subx at redfish-solutions.com>
> Cc: click at pdos.csail.mit.edu
> Date: Thursday, February 17, 2011, 2:36 PM
> But in this case, right, it doesn't
> actually matter whether we map packets to
> the "correct" ARPQuerier?? We don't expect many
> packets to get dropped, or
> even queued; it's not super performance sensitive.?
> It'd definitely be easier
> to emit packets to SOME Querier than it would be to emit
> them to the ENQUEUING
> ARPQuerier.
>
> Eddie
>
>
> On 02/17/2011 01:28 PM, Philip Prindeville wrote:
> > Yes, busted.
> >
> > It's a RouterBricks thing.
> >
> > And yes, you guessed exactly right.
> >
> >
> > On 2/17/11 11:32 AM, Eddie Kohler wrote:
> >> Hey Philip,
> >>
> >> Thanks for your patience...
> >>
> >> It is certainly possible that ARPQuerier should do
> the queueing instead of
> >> ARPTable.
> >>
> >> The "logic" for for the current behavior is as
> follows: ARP responses are
> >> sensitive to a given NIC, so if multiple
> ARPQueriers share an ARPTable, it's
> >> OK that all queued packets are emitted from
> *WHICHEVER* ARPQuerier happens
> >> to receive the response.
> >>
> >> I don't completely buy this "logic". But could you
> explain more about your
> >> application, to help me understand the ideal final
> behavior? Why do you want
> >> to share ARPTables? Is this a sort of a
> RouterBricks thing, where you have
> >> multiple ARPQueriers on different threads, writing
> to multiple output queues
> >> on THE SAME output NIC?
> >>
> >> Eddie
> >>
> >>
> >> On 02/12/2011 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
>
------------------------------
Message: 2
Date: Fri, 18 Feb 2011 16:00:45 -0800
From: Philip Prindeville <philipp_subx at redfish-solutions.com>
Subject: Re: [Click] Question about cooperating elementclasses
To: Eddie Kohler <kohler at cs.ucla.edu>
Cc: click at pdos.csail.mit.edu
Message-ID: <4D5F082D.8030001 at redfish-solutions.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Don't agree. I don't care if they get run on the same thread, but I definitely want the flow through the system maintained...
Can't really go into all the reasons on the list without compromising my employer's intellectual property, however.
On 2/17/11 2:36 PM, Eddie Kohler wrote:
> But in this case, right, it doesn't actually matter whether we map packets to the "correct" ARPQuerier? We don't expect many packets to get dropped, or even queued; it's not super performance sensitive. It'd definitely be easier to emit packets to SOME Querier than it would be to emit them to the ENQUEUING ARPQuerier.
>
> Eddie
>
>
> On 02/17/2011 01:28 PM, Philip Prindeville wrote:
>> Yes, busted.
>>
>> It's a RouterBricks thing.
>>
>> And yes, you guessed exactly right.
>>
>>
>> On 2/17/11 11:32 AM, Eddie Kohler wrote:
>>> Hey Philip,
>>>
>>> Thanks for your patience...
>>>
>>> It is certainly possible that ARPQuerier should do the queueing instead of
>>> ARPTable.
>>>
>>> The "logic" for for the current behavior is as follows: ARP responses are
>>> sensitive to a given NIC, so if multiple ARPQueriers share an ARPTable, it's
>>> OK that all queued packets are emitted from *WHICHEVER* ARPQuerier happens
>>> to receive the response.
>>>
>>> I don't completely buy this "logic". But could you explain more about your
>>> application, to help me understand the ideal final behavior? Why do you want
>>> to share ARPTables? Is this a sort of a RouterBricks thing, where you have
>>> multiple ARPQueriers on different threads, writing to multiple output queues
>>> on THE SAME output NIC?
>>>
>>> Eddie
>>>
>>>
>>> On 02/12/2011 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
End of click Digest, Vol 92, Issue 25
*************************************
More information about the click
mailing list