On Fri, 16 Nov 2001, Luigi Rizzo wrote:
> On Fri, Nov 16, 2001 at 04:02:51PM -0800, Peter Wemm wrote:
>
> > it. MT_DUMMYNET must die, not be propagated elsewhere.
>
> i agree!
>
> cheers
> luigi
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
so far there hasn't been a lot of suggestion as to how the goal can be
achieved however..
things it should be:
1/ flexible
2/ queueable
3/ transparent to 3rd party code that doesn't know about it.
i.e. if I have metadata with a packet that
is passed to a packet filter, that decides that it should be
queued (like dummynet), I want the dequeued packet to still
have that metadata with it.
If I give it to an encryption module, and get it back
I don't want the encryption module to have
deleted the metadata.
We do this in netgraph successfully, where we can store
packet priority data (for example) to ensure that
housekeeping packets overtake data packets in
frame relay. (if you don't do this the fram relay exchange will
shot down the link when it gets busy and the housekeeping
packets are delayed). We also include data to do with
throughput limits and clasification after it has passed though
a classifier node. You can't do these things unless you
have per-packet information.
The idea of the (struct mbuf * m_aux) field is fine by me
but that is still using an mbuf, which some people seem
to be against..
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
