[Click] Accessing the ingress interface of a packet

Pekka Nikander pekka.nikander at nomadiclab.com
Sat Jan 1 16:29:07 EST 2011


I'm not a click expert and definitely not a Linux kernel expert, so please take my advice with a pinch of salt.

Anyway, my understanding is that if you run Click in the Linux kernel, you already have that information in the underlying sbuf.  So, it probably won't take much to expose that if you insist.

However, my humble understanding of the Click design "way" is that you don't want to do that, but that you do want to use the annotations.  In general, it appears a good idea to add a limited amount of (mostly dynamic) metadata to packets through the annotations, and to use that metadata to let the elements to signal element-specific information to other elements downstream.

For an example, see how the various Wifi elements use annotations.

Currently there is the drawback that the annotation space is quite limited, and sometimes different elements want to use the same annotation bytes, but for simple things the annotations seem to be "the way" to go.

--Pekka

On 2011-01 -01, at 22:49 , Philip Prindeville wrote:

> So it's not kept as part of the packet's internal housekeeping?
> 
> I don't think that I've ever worked on a router where that wasn't part of a packet's state.
> 
> What would be involved in adding it as part of the intrinsic state?
> 
> 
> On 1/1/11 1:47 PM, Pekka Nikander wrote:
>> A typical way of doing that is to Paint the packet soon after receiving it from the interface, before muxing it with other traffic.  You can the use a PaintSwitch to demux it according to the interface it came through.
>> 
>> --Pekka
>> 
>> On 2011-01 -01, at 22:26 , Philip Prindeville wrote:
>> 
>>> (Forgive the newbie questions... I'm having to learn Click in a hurry as I ramp up on a project.)
>>> 
>>> Is there a built-in element that returns the ingress interface of a packet?
>>> 
>>> I'm trying to write an elementclass in Click that modifies a packet and then sends it back out the same interface it came in on, but don't want to have one instance of it per-interface that it is used on.
>>> 
>>> Thanks.
>>> 
>>> -Philip
> 




More information about the click mailing list