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 exis
* 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 kin
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 multi-instance
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
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' a
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 per
On Fri, 16 Nov 2001, Garrett Wollman wrote:
> <
>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 and metad
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
< 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 and metadata crap
should be pulled out of mbufs and put into a higher-le
> 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, 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-curr
Alfred Perlstein wrote:
>
> * 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 sche
* 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
Well I don't care exactly how we do it but we need to
figure out a way of storing such metadata along with packets.
and it needs to be queueable along with the packets..
(sounds like an mbuf to me but if you have a better idea.)
(and anyhow Garrett got rid of the 'static' uses
of mbufs, not 't
On Fri, 16 Nov 2001, Jonathan Lemon wrote:
> In article [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,
* 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
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
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 metad
In article [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" manner.
>
>Luigi has al
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 s
For work related erasons I've been in the IP stack
(basically just IP actually) recently. It's obvious
that there are re-entrancy problems there.
Here are two examples..
Routed packets:
a packet that is routed, uses a single static 'route' entry...
(In ip_input.c)
Right next to it is a sockadd
21 matches
Mail list logo
