IPD 50 Retiring fipe(4D)
#27
Conversation
|
FWIW, I think it"s 4D these days, not 7D? |
|
Oh, and, I have no idea what driver fipe is yet but if it"s delivered from the gate, and we remove it, we"ll do so not by deleting the package metadata but by changing it into an "obsolete" package. These packages deliver no actions and essentially drive the removal of the old package we"re trying to chuck out. |
|
ope, yeah, 4D. I"ll fix that up. re. packaging: good to know! that makes the "continues to work when upgraded" path make sense, thanks. |
|
It may be worth teasing out the relationship between fipe and the dcopy+ioat drivers and the driver/i86pc/ioat package. Specifically, is fipe the only consumer of the dcopy stuff? As far as I can tell, fipe does use dcopy, and the ioat (Intel I/O Acceleration Technology) bits apply to the same 5000/7300 chipset that fipe applies to. It"s not immediately obvious if there are other consumers, though. |
|
@ptribble good callout, and I"ve gotten back to some spelunking here.. my read is that ioat and dcopy could still be pretty useful, but currently are not very. without ioat, yeah, I don"t see anything using dcopy either. and it seems (this is just a quick read of fipe_pm.c) that fipe"s only interest in ioat is for the DMA engine aka "Intel QuickData". "I/O Acceleration Technology" is, it seems, the name for a whole set of features, of which QuickData might be the most useful and is still mentioned at least as recently as the Broadwell datasheet (aka the E5-2600v4 processors, Intel doc 333810-002US). so, my conclusion here is that parts of what are rolled up into ioat today could still be useful as recently as Broadwell - and anecdotally speaking at least I set up a Broadwell machine today :) it"s not clear to me how directly QuickData and AFAICT the modern equivalent, QuickAssist (aka "QuickAssist Technology", QAT), are related. did QuickData get adjusted and rebranded into QAT? would one expect ioat to be close to useful on even a modern QAT-supporting Xeon? or would ioat only be really useful on the "QuickData"-supporting processors at least through Broadwell? in that last case case, it might even just be a matter of adding the right PCI device IDs and validating. either way with or without ioat, I think dcopy is still still theoretically pretty useful, but I"m not familiar enough with really any of this kind of hardware offload to know if in practice dcopy would be suitable |
I was reading
i86pc/os/cpupmtoday and realized that thecpu_idle_enter/check_funcinteraction is a bit difficult to follow specifically in support offipe(7D). while I"m sure we could refactor it a bit, I"m concerned that it"d be hard to validate those changes without a system thatfipe(7D)can be tested on, instead maybe we ought to consider removing the whole thing. and so, here"s the IPD proposing just that.I"m mostly looking for "no! we"re still using that!" in case anyone has some old Xeon 5000/7000 systems with FBDIMM hanging around. process-wise, I"m a bit fuzzy on what would happen if
fipe(7D)were removed across some upgrade - could those systems continue to have afipedriver from before the removal? or would the upgrade also ensure that the no-longer-present package is not installed in a boot environment with the rest of a new system?