[Ns-developers] Requesting help for csma promiscuous mode

[Mathieu Lacage]

On Tue, 2008-07-08 at 11:54 +0100, Gustavo Carneiro wrote:

> Please just lets take a step back and re-consider the focus of this
> project.  Are we building a _network_ simulator or a _hardware_ simulator?

I am building a network simulator, but I agree with craig: I think that
it is totally meaningless to make the devices be always in promisc mode.
That does not mean that we need to support 20 different promisc flags
though.

> 
> >From a _hadware_ simulator POV what you say makes sense.
> 
> >From a network POV it hardly matters IMHO.  Before deciding to blindly copy
> the promiscuous mode into NS-3, let us consider why it exists in the first
> place.  The problem is that NICs communicate with the CPU via a PCI bus, in
> a PC (or a South Bridge for NICs built into the motherboard).  So there is a
> barrier with limited bandwidth.  Moreover, interrupting the CPU via a IRQ
> causes a context switch to attend the interrupt, which decreases system
> performance.  For that reason, NICs are built to only communicate to the CPU
> only when frames of interest arrive, which normally include only unicast
> frames directed to the NIC or broadcast.  Promiscuous mode is enabled on a
> as needed basis due to performance considerations.
> 
> In NS-3 we obviously have no such performance penalty.  Filtering frames at
> the Node level is just as efficient as filterering at the NetDevice level.

Yes, unless you have multiple rx callbacks in which case each callback
needs a copy of its own.


>   1- Separate promiscuous receive callback, with or without
> "promiscuous
> mode" (though I don't see the point of it);
> 
>   2- Single receive callback, but always in promiscuous mode and
> PacketType
> to make filtering easy;
> 
> I strongly advise against:
> 
>   3- Single receive callback _and_ promiscuous mode on/off switch.

Why ? That is what linux is doing and they get away with it perfectly
fine. 

> In either case, a quick final decision about this would be greatly
> appreciated.  If deciding for 1, please also advise on whether full
> backward
> API compatibility is desired or not.

It clearly is not desired.

Mathieu