| Age | Commit message (Collapse) | Author |
|---|
|
a continuous walk on the disk-queue. the implementation differs from what
jacekm@ commited (and I backed out) a while ago in that it uses a queue and
a host tree required for upcoming features.
code will be improved in tree, it requires changes to be done in queue and
bounce API, I just wanted to commit a working version first ...
tested by todd@ and I
|
|
|
|
ok miod@
|
|
ok kettenis@
|
|
No objection from kettenis@
|
|
|
|
and iir in the physical trap save area and copy into the trap frame once
back in virtual.
ok kettenis@
|
|
|
|
ok mikeb@ fries@ mpf@ henning@ dlg@ matthew@
|
|
Synchronization operations are expressed from the perspective of the host
RAM, e.g., a device -> memory operation is a READ and a memory -> device
operation is a WRITE.
the status block that the isr reads is written to by the device.
the chip writes to memory, it is therefore a READ.
this also adds the preread sync when the map is set up and the postread
sync when the map is torn down for better symmetry. there are probably
more issues like this in the code, but this is a start.
discovered while discussing another diff with claudio@
|
|
|
|
|
|
Additional testing by jasper@ and pea@
|
|
|
|
rather than looping over them until it runs out of work to do.
looping in the isr is bad for several reasons:
firstly, the chip does interrupt mitigation so you have a
decent/predictable amount of work to do in the isr. your first loop
will do that chunk of work (ie, it pulls off 50ish packets), and
then the successive looping aggressively pull one or two packets
off the rx ring. these extra loops work against the benefit that
interrupt mitigation provides.
bus space reads are slow. we should avoid doing them where possible
(but we should always do them when necessary).
doing the loop 5 times per isr works against the mclgeti semantics.
it knows a nic is busy and therefore needs more rx descriptors by
watching to see when the nic uses all of its descriptors between
interrupts. if we're aggressively pulling packets off by looping
in the isr then we're skewing this check.
ok deraadt@ claudio@
this is like src/sys/dev/pci/if_ix.c r1.50.
|
|
than looping over them until it runs out of work to do.
in my testing i have found that under what i consider high pps
(>160kpps) ix would loop 4 or 5 times in the interrupt handler,
where each loop does a bus_space_read and the mclgeti loop (ie, rx
dequeue followed by rx ring fill).
looping in the isr is bad for several reasons:
firstly, the chip does interrupt mitigation so you have a
decent/predictable amount of work to do in the isr. your first loop
will do that chunk of work (ie, it pulls off 50ish packets), and
then the successive looping aggressively pull one or two packets
off the rx ring. these extra loops work against the benefit that
interrupt mitigation provides.
bus space reads are slow. we should avoid doing them where possible
(but we should always do them when necessary).
doing the loop 5 times per isr works against the mclgeti semantics.
it knows a nic is busy and therefore needs more rx descriptors by
watching to see when the nic uses all of its descriptors between
interrupts. if we're aggressively pulling packets off by looping
in the isr then we're skewing this check.
ok deraadt@ claudio@
testing by phessler@ bluhm@ and me in production
|
|
|
|
|
|
them in files named mio_<backend>.c
No behaviour change.
|
|
|
|
|
|
some broken intel chipsets that require longer delays, we will cope with
that later hopefully.
ok kettenis
|
|
|
|
to possibly favor the mirror instead of the main ccd by incorrectly
considering the main ccd is in the failure state, for interleaved+mirrored
ccds.
ok deraadt@
|
|
thus possibly consuming all of our available kva mapping buffers for
deps. Diff and analysis actually comes from Pedro Martelleto (thanks!)
tested by me and thib
ok thib@, art@
|
|
and config files);
diff from Alexis Fouilhe
verified by millert
|
|
Diff from Alexander Polakov.
ok phessler@
|
|
others (HTTP will need a more complicated splicing mechanism to switch
between headers and bodies in userland and kernel). Add the "no
splice" flag for non-TCP relays by default to indicate it in the debug
and status output.
|
|
|
|
ok jasper@
|
|
forwarding for plain tcp connections.
feedback and ok reyk@
|
|
of a connection originator. this allows one to query the source rdomain
with a SO_RTABLE socket option. figured out with reyk, ok claudio.
|
|
|
|
|
|
|
|
|
|
Discovered, narrowed down, and tested by jmc@.
"definitely commit that" deraadt@, ok miod@
|
|
|
|
|
|
ok dcoppa@ phessler@ jasper@ landry@ rpointel@ giovanni@ ajacoutot@ henning@
no problem jmc@
|
|
defined in all of uipc_mbuf.c. I use this function a lot for quick
printf debugging.
|
|
in install image creation and no longer required.
ok deraadt@
|
|
Sprackett.
|
|
means the data size of a frame can be calculated if the dimensions
are known.
* calculate frame data sizes for uncompressed formats instead of believing
what the hardware says. the UVC spec changed between 1.0 and 1.1, and
as a result, some devices return bogus information.
* skip under-sized as well as over-sized uncompressed frames; there is
only one correct size for uncompressed frames.
* remove quirk to fix uncompressed frame sizes on certain devices,
since that now always happens.
* check that the device is actually using the parameters we think it's
using.
|
|
keep the format of the "Block device changes:" output exactly the same
as it was in the past. As a bonus, this also avoids lies in variable
names, making it more obvious what is actually being compared here.
|
|
got broken. Most /usr/src/regress/sys/kern/splice/args-oobinline-*
regression tests fail when they split an mbuf at out-of-band data.
ok claudio@, deraadt@
|
|
|
|
bitwise or it.
|
|
|
|
the screens necessary to display the line and modify head or tail
of the smap accordingly; since it might have changed due to e.g.
smaller tabstop value.
Reported by Patrick Keshishian who submitted a wrong diff and didn't
care to even test this one.
OK millert@, krw@.
|
