Sorry to join this late, I've been busy preparing other patches to roll out.
I am OK either way. FWIW we're running with this @netapp for more than 2
years, but we do use only very few drivers. I would like to avoid the
proliferation of APIs but Robert's point also does make sense.
On Sat, Nov 2
On Wed, 20 Nov 2013, Julian Elischer wrote:
After that it'd be nice to write a set of mbuf list macros for abstract the
whole queue, dequeue, concat, iterate, etc (like sys/queue.h, but for
mbufs.)
What do people think?
(I've been doing it for m->next chained things, but not m->m_nextpkt
th
On Wed, 20 Nov 2013, Adrian Chadd wrote:
We should migrate drivers to use a multi-input method where it's
appropriate. It's the same pain as if_transmit() is/was.
I'd really like to avoid having hacky solutions like mbufs with magic types.
If we're going down that path, we should create a cor
On 21 November 2013 06:36, Hooman Fazaeli wrote:
> What are possible sideeffects? What are the benefits we achieve by a
> distinct
> queue structure and having both if_input and if_input_multi?
Doing incremental development where you can minimise unintended
side-effects during development?
-a
On 11/21/2013 1:32 AM, Adrian Chadd wrote:
Can we revert this and just quickly put together something else that
won't potentially come back to bite us with weird side effects?
My suggestions (and I'm happy to do this work if needed):
* create a lightweight mbuf queue representation so an mbuf l
On 11/20/13, 4:35 PM, Luigi Rizzo wrote:
On Wed, Nov 20, 2013 at 04:07:07PM -0800, Adrian Chadd wrote:
Hi,
We should migrate drivers to use a multi-input method where it's
appropriate. It's the same pain as if_transmit() is/was.
right, and i think that is very confusing and i'd rather
not repl
On 11/20/13, 2:02 PM, Adrian Chadd wrote:
Can we revert this and just quickly put together something else that
won't potentially come back to bite us with weird side effects?
My suggestions (and I'm happy to do this work if needed):
* create a lightweight mbuf queue representation so an mbuf li
On Wed, Nov 20, 2013 at 04:07:07PM -0800, Adrian Chadd wrote:
> Hi,
>
> We should migrate drivers to use a multi-input method where it's
> appropriate. It's the same pain as if_transmit() is/was.
right, and i think that is very confusing and i'd rather
not replicate the experience.
But what is y
Hi,
We should migrate drivers to use a multi-input method where it's
appropriate. It's the same pain as if_transmit() is/was.
I'd really like to avoid having hacky solutions like mbufs with magic
types. If we're going down that path, we should create a correct
inline messaging mechanism that incl
On Wed, Nov 20, 2013 at 05:29:37PM -0500, George Neville-Neil wrote:
>
> On Nov 20, 2013, at 17:02 , Adrian Chadd wrote:
>
> > Can we revert this and just quickly put together something else that
> > won't potentially come back to bite us with weird side effects?
> >
> > My suggestions (and I'm
On Nov 20, 2013, at 17:02 , Adrian Chadd wrote:
> Can we revert this and just quickly put together something else that
> won't potentially come back to bite us with weird side effects?
>
> My suggestions (and I'm happy to do this work if needed):
>
> * create a lightweight mbuf queue represent
Can we revert this and just quickly put together something else that
won't potentially come back to bite us with weird side effects?
My suggestions (and I'm happy to do this work if needed):
* create a lightweight mbuf queue representation so an mbuf list isn't
just the mbuf header pointer;
* cre
On Wed, Nov 20, 2013 at 12:11:20PM -0800, Julian Elischer wrote:
> On 11/19/13, 3:04 AM, Robert Watson wrote:
> > On Mon, 18 Nov 2013, George V. Neville-Neil wrote:
> >
> >> Allow ethernet drivers to pass in packets connected via the
> >> nextpkt pointer.
> >> Handling packets in this way allows
On 20 Nov 2013, at 20:11, Julian Elischer wrote:
>> Currently, it is quite easy to make mistakes regarding individual mbuf
>> chains vs. lists of mbuf chains. This leads me to wonder whether a new
>> type, perhaps simply constructed on the stack before passing in, should be
>> used for KPIs
On 11/19/13, 3:04 AM, Robert Watson wrote:
On Mon, 18 Nov 2013, George V. Neville-Neil wrote:
Allow ethernet drivers to pass in packets connected via the
nextpkt pointer.
Handling packets in this way allows drivers to amortize work
during packet reception.
Submitted by:Vijay Singh
Sp
On 11/19/13, 3:04 AM, Robert Watson wrote:
On Mon, 18 Nov 2013, George V. Neville-Neil wrote:
Allow ethernet drivers to pass in packets connected via the
nextpkt pointer.
Handling packets in this way allows drivers to amortize work
during packet reception.
Submitted by:Vijay Singh
Sp
On Tue, 19 Nov 2013 22:08:21 +0100, Luigi Rizzo wrote:
On Mon, Nov 18, 2013 at 10:58:14PM +, George V. Neville-Neil wrote:
Author: gnn
Date: Mon Nov 18 22:58:14 2013
New Revision: 258328
URL: http://svnweb.freebsd.org/changeset/base/258328
Log:
Allow ethernet drivers to pass in packets
On Mon, Nov 18, 2013 at 10:58:14PM +, George V. Neville-Neil wrote:
> Author: gnn
> Date: Mon Nov 18 22:58:14 2013
> New Revision: 258328
> URL: http://svnweb.freebsd.org/changeset/base/258328
>
> Log:
> Allow ethernet drivers to pass in packets connected via the nextpkt pointer.
> Handlin
Robert Watson wrote this message on Tue, Nov 19, 2013 at 11:04 +:
> On Mon, 18 Nov 2013, George V. Neville-Neil wrote:
>
> > Allow ethernet drivers to pass in packets connected via the nextpkt
> > pointer.
> > Handling packets in this way allows drivers to amortize work during
> > packet rec
On Mon, 18 Nov 2013, George V. Neville-Neil wrote:
Allow ethernet drivers to pass in packets connected via the nextpkt pointer.
Handling packets in this way allows drivers to amortize work during packet
reception.
Submitted by: Vijay Singh
Sponsored by: NetApp
Currently, it is quite ea
On 19.11.2013 02:58, George V. Neville-Neil wrote:
Author: gnn
Date: Mon Nov 18 22:58:14 2013
New Revision: 258328
URL: http://svnweb.freebsd.org/changeset/base/258328
Log:
Allow ethernet drivers to pass in packets connected via the nextpkt pointer.
Handling packets in this way allows driv
Author: gnn
Date: Mon Nov 18 22:58:14 2013
New Revision: 258328
URL: http://svnweb.freebsd.org/changeset/base/258328
Log:
Allow ethernet drivers to pass in packets connected via the nextpkt pointer.
Handling packets in this way allows drivers to amortize work during packet
reception.
Sub
22 matches
Mail list logo
