[Ns-developers] Requesting help for csma promiscuous mode

[Gustavo Carneiro]

2008/7/8 Mathieu Lacage <mathieu.lacage at sophia.inria.fr>:

>
> 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.


I thought packet copies were supposed to be cheap in ns-3.

Besides, any performance problem associated with a higher layer filtering
strategy will become enabled as soon as the promiscuous mode is activated.
So, if there is a performance problem it should just be fixed.


>
>
>
> >   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.


OK, but Linux has a PacketType field to help protocol handlers cope with the
promiscuous mode packets.  And it works in Linux because Linux is very well
tested.


>
>
> > 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.


OK, you sort it out with Tom and Craig.  I give up arguing about this. :P

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert