Yes it is. Normally you can filter out unwanted unicast. Your stack will have to deal with all broadcast frames. If you use unicast, your stack will typically also have to deal with some, but not all, unwanted multicast frames because those are often only filtered by a hash table.
/Timmy JM wrote: > I am using a LM3S6965. The only filter I've ever come across in the > micro datasheet and driverlib datasheet is the MAC filter, which will > filter only based on MAC (I believe this is a fairly standard feature). > > --- On *Thu, 8/13/09, Alain Mouette /<[email protected]>/* wrote: > > > From: Alain Mouette <[email protected]> > Subject: Re: [lwip-users] Why so many pbufs required? > To: "Mailing list for lwIP users" <[email protected]> > Date: Thursday, August 13, 2009, 1:09 PM > > IIRC and you mentioned Luminary, there is a hardware filter so > that unwanted ports don't even find their way to the stack. This > may be very important in big LANs, specialy with lots of windows... > > If you manage to set this up, please send feedback. > > Alain > > JM escreveu: > > Ahh, never thought of the "unexpected" packets. I learn a > little more each day. > > --- On *Thu, 8/13/09, Kieran Mansley /<[email protected] > </mc/[email protected]>>/* wrote: > > > > > > From: Kieran Mansley <[email protected] > </mc/[email protected]>> > > Subject: Re: [lwip-users] Why so many pbufs required? > > To: "Mailing list for lwIP users" <[email protected] > </mc/[email protected]>> > > Date: Thursday, August 13, 2009, 9:22 AM > > > > On Thu, 2009-08-13 at 04:09 -0700, JM wrote: > > > > You're assuming that the stack will only receive packets for > your > > application. In most networks this is not true - there will > be a fair > > number of broadcasts, and other stuff that your application > will never > > see. These will still be passed to the stack, and each will > use (at > > least) one PBUF_POOL pbuf. There may be other things, such > as TCP ACKs > > for any data you send, that also come in as separate packets > and each > > use PBUF_POOL pbufs. > > > > Chris's point about using more-but-smaller pbufs in the pool > is a good > > one. It will mean you might get away with less memory and > fewer dropped > > packets, at the cost of a little extra overhead for the > chaining. > > > > Kieran > > > > > > > > _______________________________________________ > > lwip-users mailing list > > [email protected] </mc/[email protected]> > </mc/[email protected] > </mc/[email protected]>> > > http://lists.nongnu.org/mailman/listinfo/lwip-users > > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > lwip-users mailing list > > [email protected] </mc/[email protected]> > > http://lists.nongnu.org/mailman/listinfo/lwip-users > > > _______________________________________________ > lwip-users mailing list > [email protected] </mc/[email protected]> > http://lists.nongnu.org/mailman/listinfo/lwip-users > > > ------------------------------------------------------------------------ > > _______________________________________________ > lwip-users mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
