On 5 Oct 2010, at 17:01, Karim Fodil-Lemelin wrote:
> I will share some of the experience I had doing embed mtags. Hopefully its
> relevant :)
>
> The idea of carrying a certain amount of mbuf tags within the mbuf structure
> is somewhat similar but much cleaner, imo, then Linux's skbuff char
On 03/10/2010 9:13 AM, Luigi Rizzo wrote:
On Sun, Oct 03, 2010 at 12:29:21AM +0100, Rui Paulo wrote:
On 2 Oct 2010, at 21:35, Juli Mallett wrote:
On Sat, Oct 2, 2010 at 12:07, Rui Paulo wrote:
On 2 Oct 2010, at 16:29, Robert Watson wrote:
On Thu, 30 Sep 2010, Julian Elischer wrote:
On 9/3
On Sun, Oct 03, 2010 at 12:29:21AM +0100, Rui Paulo wrote:
> On 2 Oct 2010, at 21:35, Juli Mallett wrote:
>
> > On Sat, Oct 2, 2010 at 12:07, Rui Paulo wrote:
> >> On 2 Oct 2010, at 16:29, Robert Watson wrote:
> >>> On Thu, 30 Sep 2010, Julian Elischer wrote:
> On 9/30/10 10:49 AM, Ryan Ston
On 2 Oct 2010, at 21:35, Juli Mallett wrote:
> On Sat, Oct 2, 2010 at 12:07, Rui Paulo wrote:
>> On 2 Oct 2010, at 16:29, Robert Watson wrote:
>>> On Thu, 30 Sep 2010, Julian Elischer wrote:
On 9/30/10 10:49 AM, Ryan Stone wrote:
> It's not a big thing but it would be nice to replace the
On Sat, Oct 2, 2010 at 12:07, Rui Paulo wrote:
> On 2 Oct 2010, at 16:29, Robert Watson wrote:
>> On Thu, 30 Sep 2010, Julian Elischer wrote:
>>> On 9/30/10 10:49 AM, Ryan Stone wrote:
It's not a big thing but it would be nice to replace the m_next and
m_nextpkt fields with queue.h macr
On 2 Oct 2010, at 16:29, Robert Watson wrote:
> On Thu, 30 Sep 2010, Julian Elischer wrote:
>
>> On 9/30/10 10:49 AM, Ryan Stone wrote:
>>> It's not a big thing but it would be nice to replace the m_next and
>>> m_nextpkt fields with queue.h macros.
>> funny, I've never even thought of that..
>
On Thu, 30 Sep 2010, Julian Elischer wrote:
On 9/30/10 10:49 AM, Ryan Stone wrote:
It's not a big thing but it would be nice to replace the m_next and
m_nextpkt fields with queue.h macros.
funny, I've never even thought of that..
I have, and it's a massive change touching code all over the
On 9/30/10 10:49 AM, Ryan Stone wrote:
It's not a big thing but it would be nice to replace the m_next and
m_nextpkt fields with queue.h macros.
funny, I've never even thought of that..
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.o
It's not a big thing but it would be nice to replace the m_next and
m_nextpkt fields with queue.h macros.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr
On 27.09.2010 18:13, Julian Elischer wrote:
On 9/27/10 6:09 AM, Andre Oppermann wrote:
On 26.09.2010 08:32, Julian Elischer wrote:
On 9/25/10 1:20 AM, Andre Oppermann wrote:
On 25.09.2010 09:19, Julian Elischer wrote:
* dynamically working out what the front padding size should be.. per sessi
On 27.09.2010 18:09, Julian Elischer wrote:
On 9/27/10 6:14 AM, Andre Oppermann wrote:
On 27.09.2010 15:18, Luigi Rizzo wrote:
On Mon, Sep 27, 2010 at 02:55:45PM +0200, Andre Oppermann wrote:
...
my idea was to have an extra field in the mbuf to tell how much room
should be reserved/used for m
On 9/27/10 6:09 AM, Andre Oppermann wrote:
On 26.09.2010 08:32, Julian Elischer wrote:
On 9/25/10 1:20 AM, Andre Oppermann wrote:
On 25.09.2010 09:19, Julian Elischer wrote:
over the last few years there has been a bit of talk about some
changes people want to see in mbufs
for 9.x
extra fiel
On 9/27/10 6:14 AM, Andre Oppermann wrote:
On 27.09.2010 15:18, Luigi Rizzo wrote:
On Mon, Sep 27, 2010 at 02:55:45PM +0200, Andre Oppermann wrote:
...
my idea was to have an extra field in the mbuf to tell how much room
should be reserved/used for metadata (such as mtags) after
the payload ar
On 27.09.2010 15:18, Luigi Rizzo wrote:
On Mon, Sep 27, 2010 at 02:55:45PM +0200, Andre Oppermann wrote:
...
my idea was to have an extra field in the mbuf to tell how much room
should be reserved/used for metadata (such as mtags) after
the payload area so you don't need to change the allocator,
On 26.09.2010 08:32, Julian Elischer wrote:
On 9/25/10 1:20 AM, Andre Oppermann wrote:
On 25.09.2010 09:19, Julian Elischer wrote:
over the last few years there has been a bit of talk about some changes people
want to see in mbufs
for 9.x
extra fields, changes in the way things are done, etc.
On Mon, Sep 27, 2010 at 02:55:45PM +0200, Andre Oppermann wrote:
...
> >my idea was to have an extra field in the mbuf to tell how much room
> >should be reserved/used for metadata (such as mtags) after
> >the payload area so you don't need to change the allocator, and
> >possibly can even modify t
On 25.09.2010 18:30, Luigi Rizzo wrote:
On Sat, Sep 25, 2010 at 10:20:19AM +0200, Andre Oppermann wrote:
On 25.09.2010 09:19, Julian Elischer wrote:
over the last few years there has been a bit of talk about some changes
people want to see in mbufs
for 9.x
extra fields, changes in the way thing
On 9/25/10 1:20 AM, Andre Oppermann wrote:
On 25.09.2010 09:19, Julian Elischer wrote:
over the last few years there has been a bit of talk about some
changes people want to see in mbufs
for 9.x
extra fields, changes in the way things are done, etc.
If you are one of these people, pipe up now
On Sat, Sep 25, 2010 at 10:20:19AM +0200, Andre Oppermann wrote:
> On 25.09.2010 09:19, Julian Elischer wrote:
> >over the last few years there has been a bit of talk about some changes
> >people want to see in mbufs
> >for 9.x
> >extra fields, changes in the way things are done, etc.
> >
> >If yo
On 25.09.2010 09:19, Julian Elischer wrote:
over the last few years there has been a bit of talk about some changes people
want to see in mbufs
for 9.x
extra fields, changes in the way things are done, etc.
If you are one of these people, pipe up now..
to get the ball rolling..
* Add a field
over the last few years there has been a bit of talk about some
changes people want to see in mbufs for 9.x
extra fields, changes in the way things are done, etc.
If you are one of these people, pipe up now..
to get the ball rolling..
* Add a field for the current FIB.. currently this is 4 b
On 9/13/10 11:31 PM, Dave Seddon wrote:
Greetings,
Thanks for the quick response.
It sounds like dedicating some space for this in the mbuf would be the
best way forward, but the question is how much. I'm worried that most
freebsd users won't go for lots of route tables, which is why you went
22 matches
Mail list logo
