avsm changed the topic of #mirage to: mirage 2 released! party on!
rgrinberg has joined #mirage
rgrinberg has quit [Client Quit]
rgrinberg has joined #mirage
nullcat has joined #mirage
rgrinberg has quit [Ping timeout: 250 seconds]
nullcat has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
nullcat has joined #mirage
pablo_ has joined #mirage
nullcat has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
copy` has quit [Quit: Connection closed for inactivity]
pablo_ has quit [Remote host closed the connection]
insitu has joined #mirage
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
insitu has joined #mirage
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
insitu has joined #mirage
jermar has joined #mirage
<reynir>
morning hannes
<reynir>
oh sorry that was yesterday hah
<hannes>
reynir: no worries, today is also a morning ;)
mort___ has joined #mirage
<reynir>
truth!
mort___ has quit [Quit: Leaving.]
copy` has joined #mirage
<mato>
hannes: I've merged a bunch of virtio fixes, and also a fix for a nasty memory corruption bug in the interrupt handling. When you get a change you might want to re-test to see if anything has changed for you (test_ping_serve and test_blk are enough)
<hannes>
mato: yes, saw your commits... will do hopefully this evening
<hannes>
and thx!
AltGr has joined #mirage
rgrinberg has joined #mirage
agarwal1975 has joined #mirage
agarwal1975 has quit [Quit: agarwal1975]
yomimono has joined #mirage
srenatus[m] has quit [Read error: Connection reset by peer]
srenatus[m] has joined #mirage
pablo_ has joined #mirage
agarwal1975 has joined #mirage
jermar has quit [Ping timeout: 250 seconds]
balduin has quit [Ping timeout: 244 seconds]
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<yomimono>
hannes: thanks for the tcpip opam file pr, you beat me to that
insitu has joined #mirage
<hannes>
yomimono: :D
<hannes>
yomimono: I stumbled upon something installing mirage-clock-unix for no good reason...
<yomimono>
hannes: i'm mostly excited when tests pass at all
<hannes>
(nothing else in the build system knows about bisect)
<yomimono>
yes, I have a bisect branch for mirage-tcpip that I want to get working this week
<yomimono>
but easier to do when mirage-tcpip is topkg and not oasis
<yomimono>
no shortage of things to do D:
<hannes>
yomimono: these 6 lines are magical (as said, neither oasis nor topkg needs to know of it) -- but certainly is not executed in a CI system
<yomimono>
ah, sorry, I misunderstood what you were saying there -- thought you meant "I need to do this because no build systems know about bisect"
<yomimono>
no interest in having ocveralls report on it automatically?
<hannes>
it is a feature, not a bug!
<hannes>
i don't even know what ocveralls is.. once when opam knows about {coverage} (similar to {test}), I'm willing to put bisect info into opam + build system
<yomimono>
hm, interesting; I hadn't thought about opam integration with that
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
agarwal1975 has quit [Ping timeout: 260 seconds]
<pablo_>
yomimono: regarding the change to the Ipv4 functor to take a Time parameter, yes I can prepare a pull request to mirage if you give me some guidance on that
<pablo_>
for the 'don't fragment' flag, yes I was thinking more on letting TCP use that for discovering the path mtu. But is true that on other protocols -udp maybe- the user might want to set that flag explicitly as well
<yomimono>
pablo_: awesome! let me dig up a good PR for you to look at
<pablo_>
thanks ;) . The idea would be to have both pull request done together? (mirage and tcpip) ?. Maybe with tcpip not really using the parameter as first until you check if the ip fragmentation code is ok?
<yomimono>
generally what I do is submit both PRs, and make a couple of additional changes to .travis.yml that cause them to be tested against one another
<yomimono>
then (hopefully!) remember to remove those .travis.yml changes after merge
<yomimono>
in order to get automated tests to pass, I think you will need to make a branch with a version of `mirage-skeleton` where the ethifv4 example is changed to call ipv4 with the clock as well
<yomimono>
possibly more than that, but certainly at least that
<yomimono>
it's a bit tedious but good for figuring out mirage plumbing if you're interested in that sort of thing :)
insitu has joined #mirage
balduin has joined #mirage
<pablo_>
thanks, will give it a try and likely get back here on some days to ask further help ;)
rgrinberg has quit [Ping timeout: 255 seconds]
<hannes>
pablo_: while I haven't digged through the code, could you (either here or on GitHub) elaborate on the strategy for receiving fragments? (esp in the case of overlapping ones)
<hannes>
thus if fragment A (1..10) is received, then B (11..20), then C (1..15), which ones are used?
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<pablo_>
yes. In that case A and B are used, C is discarded as all its data was already received. The code is simple, it keeps an ordered list of (offset, len, data) received,
<pablo_>
and when a new fragment is received, it scan the list to put it in the right place, possible chopping it if some/all of his data is already present
<hannes>
pablo_: so the oldest fragments always win?
<pablo_>
is that, plus some other checks (to check we don't accept data with offset grater that the one marked as not-more-fragments, and things like that)
<pablo_>
yes, in this my implementation yes. In case of overlapping, the new packet is the one discarded/chopped
<pablo_>
I didn't though much about it, did was was easier, is there arguments to do the opposite and keep the new one?
<pablo_>
ah, let see
<hannes>
pablo_: no, you're doing the exact right thing I'd do as well! :) well done!
<pablo_>
:)
<pablo_>
btw, is just a list.. so o(n) on for each fragment. I didn't want to complicate the things more, assumed there is a small number of fragments per packet, that should be fine
<hannes>
(another valid option would be to discard overlapping segments completely)
<pablo_>
but might need a faster thing if we try to reuse this for tcp, and large windows
AltGr has left #mirage [#mirage]
<hannes>
pablo_: I guess you need Time to throw entries away after a reasonable waiting time -- otherwise the stack can be memory exhausted by sending fragmented ip frames (which never complete)!?
<pablo_>
yes
rgrinberg has joined #mirage
jermar has joined #mirage
<hannes>
another option would be to have the fragment cache limited in size, and get rid of the frames received earliest..
<pablo_>
hum, from the assembly policies listed on the paper (A) (B) (C), seems (A) is vulnerable, and is the one I implemented (prefer the fragments that arrived early to those arriving later), did I read it wrong?
<hannes>
uhm, i might be misremembering
<hannes>
you're reading it correctly :)
<hannes>
since you want to minimise blitting fragments together, I guess (B) would be fine
<hannes>
but only (C) is good according to that paper.. arriving last are preferred
<pablo_>
yes :/ . I'll change the code acording, this should be a rare case (overlapping) so I guess it doesn't matter we need to do some extra work on it
<hannes>
:) good that I remembered that paper talking about IP fragmentation and what can go wrong ;)
<pablo_>
:)
<yomimono>
pablo_: can you include a link to the paper in your commit message for the change?
<pablo_>
yes sure
<yomimono>
thanks! :)
<hannes>
better somewhere in the code where the design / rationale is discussed...
<yomimono>
fine by me :)
insitu has joined #mirage
tchell_ is now known as tchell
abeaumont_ has joined #mirage
insitu has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
yomimono has quit [Quit: Leaving]
rgrinberg has quit [Ping timeout: 244 seconds]
yomimono has joined #mirage
<yomimono>
canopy looks down :( getting 502 bad gateway from nginx