IRC channel logs

<damo22>Pellescours: i reworked your 2 patches for rumpkernel so that they apply to upstream branch and then merge into master

<damo22>building now

<damo22>Pellescours: https://git.zammit.org/rumpkernel-debian.git

<damo22>looks like they fixed rss_getkey or whatever was missing

<damo22>so i can drop my patch for that

<damo22>rumpnet links with bpf!

<damo22>the only thing missing is implementations of send_packet and receive_packet

<damo22>youpi: is UDP a superset of TCP?

<damo22>ie, can i treat all packets to be sent as udp?

<Pellescours>damo22: thanks perfect

<Pellescours>I would say that TCP being a superset of UDP

<damo22>i dont know what data is coming into rumpnet device_write/device_read

<damo22>is it link layer?

<Pellescours>TCP is statefull (connection with high confidence of remote getting packet) while UDP is stateless (you send packet and hope the remote get it)

<Pellescours>both are layer 3 (just above ip)

<damo22>if pfinet tries to send a udp packet for dhcp, will it arrive in rumpnet device_write() as a raw udp packet?

<damo22>or will it have more headers

<Pellescours>I don't know, but isn't DHCP a arp level protocol (because client don't have yet an ip)?

<damo22>no

<damo22>device is configured with 0.0.0.0 i think

<damo22>so the broadcast to 255.255.255.255 hits it

<Pellescours>ah right

<damo22>although that might be a hack

<ZhaoM>so CLOCK_MONOTONIC is mainly used for meansuring code duration?

<ZhaoM>measuring

<youpi>damo22: TCP is a superset of UDP in terms of features

<youpi>but they are separate protocols, both on top of IP

<youpi>device_write/read are ethernet frames, yet another level (2)

<youpi>so ethernet+ip+udp (or tcp)

<youpi>ZhaoM: that's the idea, though I wouldn't phrase it this way

<youpi>in that it's not just local code duration, it's a global clock that different processes can compare with each other

<youpi>but local to the computer

<youpi>you can see it as the local time in the Einstein terms: it's the time as the local machine sees it flow

<damo22>youpi: does pfinet always call device_read/write on a whole number of packets? ie i dont need to keep state in rumpnet to resume half a packet?

<youpi>yes, only whole packets

<youpi>rumpnet doesn't need state at all

<damo22>gooood

<ZhaoM>youpi: Got it. BTW I like the analogy

<youpi>that's why we can kill it without problem

<youpi>(I do it quite often for netdde when it hangs)

<damo22>is there a documentation on ethernet frames?

<youpi>ZhaoM: although it's not exactly true in that clock_monotonic should try to follow the pace of clock_realtime in terms of measuring time

<youpi>if the computer has a hardware clock that is a bit too slow, we should compense for this, and CLOCK_MONOTONIC follow that

<youpi>but it's really compensation, not abrupt changes

<youpi>damo22: wikipedia ? :)

<youpi>or my network course ? :)

<youpi>ethernet is very trivial actually: destination/source mac addresses, and the type of payload (ipv4/v6/arp/something else)

<damo22>i just need a struct somewhere

<damo22>for the header + raw data packet

<youpi>see the ethhdr struct in if_ether.h

<damo22>is the data packet always MTU in size?

<damo22>theres no size field in the eth hdr

<youpi>the size is passed as parameter

<youpi>on the wire there is an ending special encoding

<ZhaoM>it's wierd that $(glibc-2.40)/sysdeps/mach/clock_gettime.c does not have implementation for CLOCK_MONOTONIC case but I can still read something using clock_gettime (CLOCK_MONOTONIC...)

<ZhaoM>:/

<ZhaoM>youpi: which part of gnumach source code should I try to read for implementing CLOCK_MONOTONIC?

<damo22> https://en.wikipedia.org/wiki/Ethernet_frame#/media/File:Ethernet_Type_II_Frame_format.svg

<damo22>do i just support this?

<youpi>ZhaoM: in the debian package we patch of this by making CLOCK_MONOTONIC just use the CLOCK_REALTIME

<youpi>ZhaoM: kern/mach_clock.c

<ZhaoM>youpi: ok

<damo22>youpi: does pfinet only send one packet at a time to device_read/write ?

<damo22>with size param

<youpi>but also look in the list archives, iirc there were already some existing unfinished work

<youpi>damo22: only one whole packet at a time, yes

<damo22>ah thats easy then

<youpi>(one frame, more exactly, packet would be IP)

<youpi>yes it is really simple

<youpi>network drivers usually already work just that way (xmit/recv)

<youpi>the svg is that, yes (without the crc, which is handled by the hardware)

<damo22>youpi: send_packet wants the ip header as a separate blob

<damo22>does it have a fixed size

<damo22>?

<youpi>which send_packet?

<youpi>ip headers don't have a fixed size, no

<youpi>but I don't understand why you are talking about ip packets

<youpi>you shouldn't have to delve with it

<youpi>since pfinet gives you ethernet frames

<youpi>and wants that

<damo22>bpf wants a struct iovec [3]

<damo22>so i can call writev()

<youpi>doesn't bpf take an ethernet frame?

<youpi>or does it take eth/ip/tcp-udp separately?

<damo22>yes separately

<youpi>ugh

<youpi>so you have to split, ok :/

<youpi>the ip header size is given in the ip hdrlen field

<youpi>it is given in number of 32bit words

<youpi>so usually it is just 5, the minimum (no option)

<damo22> /* Fire it off */

<damo22> iov [0].iov_base = ((char *)hw);

<damo22> iov [0].iov_len = hbufp;

<damo22> iov [1].iov_base = ((char *)ip);

<damo22> iov [1].iov_len = ibufp;

<damo22> iov [2].iov_base = (char *)raw;

<damo22> iov [2].iov_len = len;

<damo22>so i think hw is the ethernet header , ip is the ip header and raw is the packet

<youpi>that looks so, yes

<damo22>but since they are just pointers, it should be some easy pointer arithmetic

<youpi>yes

<youpi>also, you should use the totlen field of the ip header to compute the payload length

<youpi>the ethernet frame could be longer for whatever reason

<damo22>ok

<ZhaoM>youpi: it seems elapsed_ticks in mach_clock.c is the CLOCK_MONOTONIC we want

<ZhaoM>so we just need to add a routine for reading elapsed_ticks in mach_host.defs and an implementation reading elapsed_ticks in mach_clock.c?

<ZhaoM>and a case for CLOCK_MONOTONIC in glic

<ZhaoM>glibc

<damo22>no i think that is only updated once per clock interrupt

<damo22>so the timer will be accurate only to 0.01s

<damo22>Sending on Socket//dev/wm0

<damo22>sent packet success

<damo22>DHCPDISCOVER on /dev/wm0 to 255.255.255.255 port 67 interval 3

<damo22>sent packet success

<damo22>DHCPDISCOVER on /dev/wm0 to 255.255.255.255 port 67 interval 4

<damo22>.... never gets IP

<damo22>i wonder if its being packet filtered by bpf

<damo22>or the reply might be

<ZhaoM>damo22: ah indeed :/

<ZhaoM>so there is precision requirement?

<youpi>ZhaoM: probably

<youpi>in the idea

<youpi>then you may want to refine the clock precision indeed

<youpi>I don't remember if we have already something for that, but that's fine: clock are not supposed to be infinitely precise

<youpi>having 10ms precision is already enough for most usages actually

<youpi>posix etc. don't require more

<ZhaoM>youpi: ok then I will try to investigate how to refine the precision

<ZhaoM>Good night guys

<youpi>sneek: later tell ZhaoM as I said: it's not really needed to get a better precision, the current clock precision is fine for most use, it's having a *monotonic* clock that would be useful, even if at the same precision as we have now

<sneek>Will do.

<ZhaoM>hi

<sneek>Welcome back ZhaoM, you have 1 message!

<sneek>ZhaoM, youpi says: as I said: it's not really needed to get a better precision, the current clock precision is fine for most use, it's having a *monotonic* clock that would be useful, even if at the same precision as we have now

<ZhaoM>youpi: ok

<youpi>heh, thanks sneek, exactly what was needed :)

IRC channel logs

2024-12-14.log