;[EMAIL PROTECTED]>
Sent: Sunday, November 18, 2001 12:46 PM
Subject: Re: re-entrancy and the IP stack.
> > err, where is BSDcon this year?
>
> Here ya go:
>
> Hotel Information
> Cathedral Hill Hotel
> 1101 Van Ness Avenue
> San Francisco, California 94109
>
> err, where is BSDcon this year?
Here ya go:
Hotel Information
Cathedral Hill Hotel
1101 Van Ness Avenue
San Francisco, California 94109
Toll Free: 1 800 622 0855
Local Telephone: 1 415 776 8200
Reservation Fax: 1 415 441 2841
Email: [EMAIL PROTECTED]
Later,
George
To Unsubscribe: send mail
err, where is BSDcon this year?
On Sun, 18 Nov 2001, George V. Neville-Neil wrote:
> I won't be at LISA but would be interested in hearing what y'all come up with.
>
> BSDCon is in my home town so it's a doddle to make it there for me.
>
> Later,
> George
>
>
>
> To Unsubscribe: send mail t
I won't be at LISA but would be interested in hearing what y'all come up with.
BSDCon is in my home town so it's a doddle to make it there for me.
Later,
George
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
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
On Sat, 17 Nov 2001, Garrett Wollman wrote:
:
:I will not be going to BSDcon absent some sugar daddy paying the
:freight.[1] I will be at LISA in San Diego (on my employer's dime) and
:could discuss this with whoever might make it there.
I'm in the SD area and unfortunately I'll not be able to g
<
said:
> Are y'all going to discuss this at BSDCon? I'm probably going there
> and would like to contribute if I could.
I will not be going to BSDcon absent some sugar daddy paying the
freight.[1] I will be at LISA in San Diego (on my employer's dime) and
could discuss this with whoever migh
* 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-net" 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
< said:
> I'd be happy with a HAS_A(mbuf), as long as I have SOMEWHERE,
> to stash the metadata.
Mind, you don't put the metadata there; you put that in the packet
structure (or rather, in the ip_packet etc. structures). I'd like to
get rid of mbufs entirely, but that's a whole 'nother kettle
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
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
* 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-net" 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
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
25 matches
Mail list logo
