<mithro>
sb0: I doubt I'm going to get a chance to look at it for atleast a week, so just going to force my build scripts to make conda go back to 3.5 for now
kuldeep has quit [Remote host closed the connection]
kuldeep has joined #m-labs
<whitequark>
sb0: re DRTIO: good question
<whitequark>
IMO builds are slow enough already...
<whitequark>
re buffering: if you call write_u8 ten times, it will not send ten packets
<whitequark>
it'll buffer them. in fact that path is cheap enough that adding a BufWriter (as it's recommended for a hosted TcpSocket) generally results in degraded performance and not improved
<GitHub>
[artiq] whitequark commented on issue #673: That pessimizes large RPCs. We have to spend the RAM twice: once on the comms CPU (to buffer the packet), then on the kernel CPU (to actually unpack it). And every time someone complains, we need to do the layout change dance, which is what prompted me to fix it.... https://github.com/m-labs/artiq/issues/673#issuecomment-282482059
<GitHub>
[artiq] whitequark commented on issue #673: I suppose one way we could fix this without changing the networking code is add a separate watchdog thread that interrupts the session thread if the watchdog ever expires. But this is annoying because of all the data sharing. https://github.com/m-labs/artiq/issues/673#issuecomment-282482113
<whitequark>
sb0: do I understand it right that the DMA engine can DMA from any memory region?
<whitequark>
if yes, we don't need to keep the DMA mapping strictly linear
<whitequark>
it can just live in kernel CPU's memory space as usual
<GitHub>
[artiq] klickverbot commented on issue #673: You could also do the message processing in a fiber, context-switching back to normal execution every time you block waiting for input. Then again, requiring 2 x max_message_size in RAM isn't unreasonable, especially since you usually have to unpack the contents of the message somewhere else as well (making it 3x anyway). You could also think about application-side chunking for very large datasets, if that i
rjo has quit [Read error: Connection reset by peer]
<GitHub>
[artiq] klickverbot commented on issue #673: (Fibers/green threads/… would also give you proper handling of multiple connections for free, although I must admit I'm not quite sure what the current story with the Rust runtime is there.) https://github.com/m-labs/artiq/issues/673#issuecomment-282487822