On Fri, 16 Nov 2001, Luigi Rizzo wrote:
> > so far there hasn't been a lot of suggestion as to how the goal can be
> > achieved however..
> i actually suggested one i.e. have explicit pointers
> to metadata area(s) in the pkthdr. I think you forget the
> most fundamental feature which is performance.
> This is way more important than flexibility i think.
Which is the reason that this problem exists..
no-one ever thinks that people will want to do things different
to what they want to do at the time they write it..
Flexibility is I think much more important than you suggest.
Wouldn't it have made it easier for you if there had been a flexible
method to pass such information available?
The m_aux field sounds right to me.
Alternatively, the ability to define a separate
data area in an M_HDR mbuf..
(There's a lot of wasted space there in M_EXT packets.)
The metadata would be there regardless of whether the
M_EXT flag was set or not.
> > things it should be:
> > 1/ flexible
I.e Don't screw over Luigi's NEXT project, Dummynet2.
> > 2/ queueable
I want to let dummynet2 do queuing of packets and keep my 'class'
information with each packet.
> > 3/ transparent to 3rd party code that doesn't know about it.
I don't want My module to have to know about the stuff Dummynet2
is storing with the packet, and I don't want dummynet2
to need to know what I have stashed in there..
If I free a packet, I shouldn't produce a leak of some other
items somewhere else. (they should describe how they should be freed!)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message