- fsqueue->setup() performs the queue initialization;
- fsqueue->message() controls messages;
- fsqueue->envelope() controls envelopes;
This commit brings the following to fsbackend:
fsqueue_setup(), fsqueue_message_delete(), fsqueue_envelope_load(),
fsqueue_envelope_update(), fsqueue_envelope_delete().
It also makes smtpd use the queue_backend API for these operations.
disk-based queue, it makes it near impossible to make changes to it without
editing twenty files... how am i going to implement mongodb support ? :-)
bring a new queue_backend API which hides the details of the disk-based
queue to smtpd. it is not "plugged in" yet and I'm filling the holes.
when leaving. when you're handling an interrupt it is masked.
whacking the chip is work for no gain.
modify the interrupt handler so it only processes the rings once,
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 henning@ krw@
testing by sthen@
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
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@
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
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@
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.
