proteusguy has quit [Remote host closed the connection]
zng has quit [Ping timeout: 248 seconds]
proteusguy has joined #m-labs
zng has joined #m-labs
rohitksingh_work has joined #m-labs
rohitksingh has joined #m-labs
gric_ has joined #m-labs
gric has quit [*.net *.split]
<rjo>
whitequark: ack the io traits/async.
<rjo>
whitequark: how do other implementations expose the socket buffers? do they either no-peek, or up-to-wrap-around, or do they copy?
rohitksingh has quit [Ping timeout: 258 seconds]
<rjo>
whitequark: i see the dma issue. would the solution be to split poll() into something that **only** shovels between the socket buffers and the dma buffers in a lock free fashion in irq context and somethine else that does the rest (protocols etc) taking &mut SocketSet?
<rjo>
i wonder whether people use the fact that with some ethernet dma implementation it might even be possible do networking completely without copy: there (on stm32h7 e.g.) the dma buffers are scatter gather and you might be able to point them directly into the socket buffers (raw sockets only obviously).
<rjo>
but the zero-copy thing is also not my main goal here. it probably doesn't make a big difference. this is more about ergonomics and designing this to have fewer chances of contention.
lkcl has quit [Ping timeout: 248 seconds]
<rjo>
whitequark: one other thing that i haven't been able to debug http://paste.debian.net/1089036/ (this is the rtfm branch of stabilizer but it has existed always since i got the first icmp packaets to work). i can't find anything in the code that could do a 1024 ms delay. also tcp works flawlessly without any delays.
m4ssi has joined #m-labs
rohitksingh has joined #m-labs
lkcl has joined #m-labs
<adamgreig>
rjo: I've seen that exact behaviour before (alternating quick and 1ms rtt), since early smoltcp, but I think I put it down to only processing poll on a 1ms systick at the time (?), you might try pinging more frequently (e.g. -f or -i 0.2 or something)
<adamgreig>
I vaguely recall seeing it go away after calling poll from the dma isr instead but might be misremembering and don't have any hw with me
<adamgreig>
I don't remember why I thought the systick thing made sense and I certainly can't guess now :p
vup has quit [Ping timeout: 258 seconds]
vup has joined #m-labs
rqou has quit [Quit: ZNC 1.7.x-git-709-1bb0199 - http://znc.in]
<rjo>
adamgreig: yes. the icmp replies bunch up in pairs. iirc i also tried busy-poll() ing without any delay. and that didn't change anything.
<adamgreig>
rjo: it seemed to me like receiving a new echo request pushed the previous one out the stack as well, so if you sent two requests per second you saw 500ms and 1ms delays
<rjo>
i.e. every other icmp reply is emitted on the subsequent request/reply.
<adamgreig>
Yea
<adamgreig>
Off by one in the dma processing maybe
<adamgreig>
Wonder if tcp just masks it
<rjo>
adamgreig: i haven't seen any similar symptom in tcp. i have the feeling it's icmp specific.
<rjo>
well. i have seen some tcp syn-ack delays but that was due to bad logic/structure in the main loop.
<adamgreig>
I wrote my own stm32 driver so you'd hope we hadn't both made the same error
<adamgreig>
But I'm pretty sure I fixed this in the end and had immediate replies to all ping packets
<rjo>
i deliberatrly did some off-by-one in the dma code and the look very different (massive effect on icmp and tcp).
<adamgreig>
On holiday all week so can't check til Saturday anyway
<adamgreig>
Not without remote rebooting a production system into its smoltcp bootloader anyway :p
<rjo>
i stole code from you, from astro's adc2tcp, from ionpak
<adamgreig>
I thought astro wrote his own driver
<rjo>
well they all look somewhat similar. also this is stm32h7 which is pretty different in the MAC/DMA area (e.g. could do scatter-gather).
<adamgreig>
yea
<adamgreig>
I'll see if I can double check tonight
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh_work has joined #m-labs
rohitksingh has quit [Ping timeout: 245 seconds]
rohitksingh has joined #m-labs
<rjo>
thanks. no rush. this is not really bothering me too much.
rqou has joined #m-labs
<Astro->
fwiw, the zynq ethernet can do scatter-gather too
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh_work has joined #m-labs
rohitksingh has quit [Ping timeout: 258 seconds]
zng has quit [Ping timeout: 244 seconds]
zng has joined #m-labs
nurelin_ has quit [Ping timeout: 245 seconds]
nurelin_ has joined #m-labs
<whitequark>
rjo: "how do other implementations expose the socket buffers?" well... they don't. at all.
<whitequark>
which is why we have the whole user mode networking thing with completely custom packet response logic
<whitequark>
peek() already is an API that's generally not provided
<whitequark>
rjo: "split poll()" that sounds a bit like "what if it magically worked"
<whitequark>
because to even know which socket to shovel data into, you have to parse it, right
<whitequark>
and by the time you've parsed the IP and TCP header, there is not that much actually left
<whitequark>
you could possibly delay running the state machine. but i don't know how to even make it work in safe rust without horribly inverting control flow
<whitequark>
and it wouldn't buy that much anyway
<whitequark>
the most costly parts of TcpSocket::process() are the logging statements I think
<whitequark>
"DMA directly into raw sockets" that doesn't make sense
<whitequark>
if you're only interested in raw sockets (and this technique can't work with non-raw sockets) then you simply throw out phy, iface and socket layers of smoltcp
<whitequark>
and use the wire layer directly
<whitequark>
because those layers don't actually do much beyond checking the destination IP and adding a ton of overhead
<whitequark>
in the case of using only raw sockets that is
<whitequark>
rjo: regarding icmp. i have some suspicions. do you have trace logs?
<rjo>
yes. peek is not new and good. to me it's a core piece in using the socket buffer from the application.
<rjo>
right. trying to do only data shoveling in the irq doesn't work. the header and state processing that would need to be done as well. can it be split it closer to the other end? i.e. you would also pend the irq that does poll() when a socket has been dirtied. poll would do a similar amount of work it does now. and the non-irq side of accessing the sockets would use some lock free mechanism to control socket
<rjo>
data.
<rjo>
dma and raw sockets makes a lot of sense. but you are right: it wouldn't use much of smoltcp.
<rjo>
i don't have trace logs right now and it might be hard to get them. but i'll try to do that once i have time.
<whitequark>
i don't know of any usable lock-free mechanism here
<rjo>
*peek is new
<whitequark>
the problem is primarily that there are two ring buffers, data and metadata
<whitequark>
if it was *only* a data ring buffer, i have some code that can handle it. it relies on a consume and produce pointers being word sized, and uses an ll/sc loop essentially
<whitequark>
unfortunately, both udp and tcp also need metadata buffers.
<whitequark>
as far as i'm aware any solution that allows to atomically append a chunk of data and a chunk of metadata involves some kind of GC
<rjo>
metadata for TCP is the endpoints + the TCP FSM state?
<whitequark>
rjo: reassembler, mostly
<whitequark>
or rather: if there was a solution for the reassembler, everything else could probably be fixed too
proteusguy has quit [Remote host closed the connection]
sb0 has quit [Quit: Leaving]
proteusguy has joined #m-labs
<_whitenotifier-3>
[nmigen-boards] alexhude opened pull request #8: Fix resource numeration to avoid overlapping with PMOD. - https://git.io/fjwpq
<_whitenotifier-3>
[m-labs/nmigen-boards] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjwpm
<_whitenotifier-3>
[m-labs/nmigen-boards] alexhude 947a7f4 - icebreaker: Fix resource numeration to avoid overlapping with PMOD.
<_whitenotifier-3>
[nmigen-boards] whitequark closed pull request #8: Fix resource numeration to avoid overlapping with PMOD. - https://git.io/fjwpq
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
<_whitenotifier-3>
[nmigen] DurandA opened issue #107: Using Verilog attribute on Instance - https://git.io/fjrem
m4ssi has quit [Remote host closed the connection]
rohitksingh has quit [Ping timeout: 246 seconds]
lkcl has quit [Ping timeout: 258 seconds]
rohitksingh has joined #m-labs
<_whitenotifier-3>
[nmigen] whitequark commented on issue #107: Using Verilog attribute on Instance - https://git.io/fjrUB
<_whitenotifier-3>
[nmigen] whitequark commented on issue #107: Using Verilog attribute on Instance - https://git.io/fjrUu
rohitksingh has quit [Ping timeout: 248 seconds]
rohitksingh has joined #m-labs
rohitksingh has quit [Remote host closed the connection]