[Ns-developers] Requesting help for csma promiscuous mode
mathieu.lacage at sophia.inria.fr
Tue Jul 8 08:40:25 PDT 2008
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
> >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
> mode" (though I don't see the point of it);
> 2- Single receive callback, but always in promiscuous mode and
> 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
> In either case, a quick final decision about this would be greatly
> appreciated. If deciding for 1, please also advise on whether full
> API compatibility is desired or not.
It clearly is not desired.
More information about the Ns-developers