Julian Elischer writes:
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..
Are y'all going to discuss this at BSDCon? I'm probably going there
and would like to contribute if I could.
Later,
George
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
I recommend you all look at The Click Modular router
http://www.pdos.lcs.mit.edu/click/
which is a step in the right direction.
Of course given the current architecture it may be very hard
to adapt it to this kind of model.
I led/worked on a project at Wind River Systems to do a
* George V. Neville-Neil [EMAIL PROTECTED] [07 16:17] wrote:
I recommend you all look at The Click Modular router
http://www.pdos.lcs.mit.edu/click/
which is a step in the right direction.
Of course given the current architecture it may be very hard
to adapt it to this kind of
Julian Elischer wrote:
[..]
What is needed is obviously a 'per packet' storage location
for those things, defined in a per protocol family manner.
Luigi has already tried this scheme by defining a
dummynet specific mbuf type that can be prepended to the
front of packets. What I suggest
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write:
As another example, the ipfw code uses a couple of static
variables too, in the 'fwd' code amongst other places..
What is needed is obviously a 'per packet' storage location
for those things, defined in a per protocol family
struct pkthdr already has a field (struct mbuf *aux)
which i think is used to store info per-packet
state by ipsec, at least according to the comment
(my dummynet hack predated this, i would have used
this field if it had been available at the time).
So this field could be used to access the
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
* Peter Wemm [EMAIL PROTECTED] [06 18:02] wrote:
Julian Elischer wrote:
[..]
What is needed is obviously a 'per packet' storage location
for those things, defined in a per protocol family manner.
Luigi has already tried this scheme by defining a
dummynet specific mbuf type that
On Fri, 16 Nov 2001, Jonathan Lemon wrote:
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write:
As another example, the ipfw code uses a couple of static
variables too, in the 'fwd' code amongst other places..
What is needed is obviously a 'per packet' storage location
* Julian Elischer [EMAIL PROTECTED] [06 18:20] wrote:
On Fri, 16 Nov 2001, Jonathan Lemon wrote:
Um, no please. MT_DUMMYNET is a bad hack that should be removed
(and which I've partly done in one of my trees). I would rather
not perpetuate this, it causes more problems than it is
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
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
On Fri, 16 Nov 2001 16:13:41 -0800 (PST), Julian Elischer [EMAIL PROTECTED] said:
(and anyhow Garrett got rid of the 'static' uses
of mbufs, not 'travelling' 'per packet' uses..)
Only because I did not have the time or stomach then to introduce
`struct packet' everywhere. All of the queueing
ok, so how would you envision it? example?
Adding fields to the pkthdr? (and flags to say
what they are used for).
A pointer to route,
(maybe the route in ip_forward() can be dynamically allocated on the
stack, I'm not sure yet)
A pointer to a sockaddr, with a flag to say if it's for
'fwd' use
On Fri, 16 Nov 2001, Garrett Wollman wrote:
On Fri, 16 Nov 2001 16:13:41 -0800 (PST), Julian Elischer [EMAIL PROTECTED]
said:
(and anyhow Garrett got rid of the 'static' uses
of mbufs, not 'travelling' 'per packet' uses..)
Only because I did not have the time or stomach then to
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
In my MAC tree, I add an additional:
struct mbuf *aux; /* extra data buffer; ipsec/others */
+ struct mac label; /* label of data in packet */
};
As we move towards more generalized access control, it would similarly be
nice to have a place to 'hang'
18 matches
Mail list logo
