Peter Memishian wrote:
> > I found there are two problems:
> >
> > 1. When ce driver sends a packet, it loops back the packet is the stream
> is
> > in the DL_PROMISC_SAP mode, which is incorrect. The packet should only be
> > loop back if the stream is in DL_PROMISC_PHYS mode.
> >
> > 2. When ce loops back the packet, it calls dupmsg() to duplicate the
> > message. But dupb() does not copy the b_flags flag as copyb() does. This
> > makes the MSGNOLOOP flag to be removed.
> >
> > The MSGNOLOOP flag is set when Nemo sents the packets down to the legacy
> > driver. It is used by Nemo to identify this kind of packets looped back
> from
> > legacy drivers. For example, in aggr_recv_cb() function, there is code
> like:
> >
> > /*
> > * If this message is looped back from the legacy devices, drop
> > * it as the Nemo framework will be responsible for looping it
> > * back by the mac_txloop() function.
> > */
> > if (mp->b_flag & MSGNOLOOP) {
> > ASSERT(mp->b_next == NULL);
> > freemsg(mp);
> > return;
> > }
> >
> > My question is: If I copy the b_flags flag in dupb() function, will it
> cause
> > any problem?
>
> Great question. In general, I'd say no, just because a lot of code uses
> dupb() and copyb() (or dupmsg() and copymsg()) in sequence -- i.e., they
> first try dupb()/dupmsg() and if that fails they try copyb()/copymsg().
> Also, having dupb() copy b_flags is consistent with the manpage, which
> states "The new mblk_t structure contains the same information as the
> original." That said, it's never copied b_flags, so who knows what you
> might smoke out by making such a change.
>
I feel the risk of making the change is minimal too. There are lots of codes
either call copymsg() or dupmsg() based on some policy (say, whether
zero-copy is used).
I will ask the same question in the network-discuss alias. If no one objects
there, I will just make the change. Hopefully we can catch problems during
our testing phase if there is any.
Thanks
- Cathy
