| /openbsd/sys/net/ |
| H A D | ifq.h | ea47e5e1 Fri Dec 15 01:37:30 GMT 2017 dlg <dlg@openbsd.org> add ifiqueues for mp safety and nics with multiple rx rings.
currently there is a single mbuf_queue per interface, which all
rings on a nic shove packets onto. while the list inside this queue
is protected by a mutex, the counters around it (ie, ipackets,
ibytes, idrops) are not. this means updates can be lost, and reading
the statistics is also inconsistent. having a single queue means
that busy rx rings can dominate and then starve the others.
ifiqueue structs are like ifqueue structs. they provide per ring
queues, and independent counters for each ring. when ifdata is read
for userland, these counters are aggregated. having a queue per
ring now allows for per ring backpressure to be applied. MCLGETI
will have it's day again.
right now we assume every interface wants an input queue and
unconditionally provide one. individual interfaces can opt into
more.
im not completely happy about the shape of this atm, but shuffling
it around more makes the diff bigger.
ok visa@
|
| H A D | ifq.c | ea47e5e1 Fri Dec 15 01:37:30 GMT 2017 dlg <dlg@openbsd.org> add ifiqueues for mp safety and nics with multiple rx rings.
currently there is a single mbuf_queue per interface, which all
rings on a nic shove packets onto. while the list inside this queue
is protected by a mutex, the counters around it (ie, ipackets,
ibytes, idrops) are not. this means updates can be lost, and reading
the statistics is also inconsistent. having a single queue means
that busy rx rings can dominate and then starve the others.
ifiqueue structs are like ifqueue structs. they provide per ring
queues, and independent counters for each ring. when ifdata is read
for userland, these counters are aggregated. having a queue per
ring now allows for per ring backpressure to be applied. MCLGETI
will have it's day again.
right now we assume every interface wants an input queue and
unconditionally provide one. individual interfaces can opt into
more.
im not completely happy about the shape of this atm, but shuffling
it around more makes the diff bigger.
ok visa@
|
| H A D | if_loop.c | ea47e5e1 Fri Dec 15 01:37:30 GMT 2017 dlg <dlg@openbsd.org> add ifiqueues for mp safety and nics with multiple rx rings.
currently there is a single mbuf_queue per interface, which all
rings on a nic shove packets onto. while the list inside this queue
is protected by a mutex, the counters around it (ie, ipackets,
ibytes, idrops) are not. this means updates can be lost, and reading
the statistics is also inconsistent. having a single queue means
that busy rx rings can dominate and then starve the others.
ifiqueue structs are like ifqueue structs. they provide per ring
queues, and independent counters for each ring. when ifdata is read
for userland, these counters are aggregated. having a queue per
ring now allows for per ring backpressure to be applied. MCLGETI
will have it's day again.
right now we assume every interface wants an input queue and
unconditionally provide one. individual interfaces can opt into
more.
im not completely happy about the shape of this atm, but shuffling
it around more makes the diff bigger.
ok visa@
|
| H A D | if_var.h | ea47e5e1 Fri Dec 15 01:37:30 GMT 2017 dlg <dlg@openbsd.org> add ifiqueues for mp safety and nics with multiple rx rings.
currently there is a single mbuf_queue per interface, which all
rings on a nic shove packets onto. while the list inside this queue
is protected by a mutex, the counters around it (ie, ipackets,
ibytes, idrops) are not. this means updates can be lost, and reading
the statistics is also inconsistent. having a single queue means
that busy rx rings can dominate and then starve the others.
ifiqueue structs are like ifqueue structs. they provide per ring
queues, and independent counters for each ring. when ifdata is read
for userland, these counters are aggregated. having a queue per
ring now allows for per ring backpressure to be applied. MCLGETI
will have it's day again.
right now we assume every interface wants an input queue and
unconditionally provide one. individual interfaces can opt into
more.
im not completely happy about the shape of this atm, but shuffling
it around more makes the diff bigger.
ok visa@
|
| H A D | if.c | ea47e5e1 Fri Dec 15 01:37:30 GMT 2017 dlg <dlg@openbsd.org> add ifiqueues for mp safety and nics with multiple rx rings.
currently there is a single mbuf_queue per interface, which all
rings on a nic shove packets onto. while the list inside this queue
is protected by a mutex, the counters around it (ie, ipackets,
ibytes, idrops) are not. this means updates can be lost, and reading
the statistics is also inconsistent. having a single queue means
that busy rx rings can dominate and then starve the others.
ifiqueue structs are like ifqueue structs. they provide per ring
queues, and independent counters for each ring. when ifdata is read
for userland, these counters are aggregated. having a queue per
ring now allows for per ring backpressure to be applied. MCLGETI
will have it's day again.
right now we assume every interface wants an input queue and
unconditionally provide one. individual interfaces can opt into
more.
im not completely happy about the shape of this atm, but shuffling
it around more makes the diff bigger.
ok visa@
|