It is great that if_virt gets a speed up, it was not excessively fast the last time I tried it. To be honest, I recently had trouble keeping up with the discussions on this list in detail, although I try to maintain the general picture.
Also, thank you for forcing me to look up jumbo frames and TSO again, I had them completely confused. Neither was enabled, though, which is why I suspect a netmap bug has caused the trouble. I have another question: Is it OK to use the rump_sys_ methods, or would it be faster to do fork and schedule manually? You write that the rumpns_sendto method calls curlwp itself, so it should actually not matter that I simply replaced the normal system call sento with rump_sys_sendto, should it? In you dissertation, you mention that scheduling manually is only necessary if you are missing the wrapper, or have I missed something there? Thanks a lot for you patience! Martin Am 16.03.2014 19:18, schrieb Antti Kantee: > On 16/03/14 17:55, Martin Unzner wrote: >>> You'll also have to enable the capabilities with ifconfig. >> Is there a rump_pub method / an ioctl call to perform that step? I do >> not want to include rumprun in my sufficiently complicated setup (you >> might have spotted the wiki article). > No, there's none, but of course we could add one. > > I might be able to get away with cheating and setting same flags to be > also enabled directly in the driver initialization, though > (ifp->if_capenable). > >>> Then you probably have to look at some mbuf >>> flags to determine how to signal your backend (netmap?) what it actually >>> needs to do to get the packet properly sent. >> I thought it would be enough to write the jumbo frame to the busfile >> as-is, and then, before writing it to the physical hardware, split it >> into netmap buffers signed with netmap's NS_MOREFRAG flag. Maybe that >> was the step you were referring to. In the other direction, it works >> that way: I can receive jumbo frames without any further setup, which I >> then dump onto the bus. The Rump kernel allocates a sufficiently large >> mbuf using MEXTMALLOC. It seems to me that the problem are the upper >> layers which reject the frame if they are not told that it's OK to >> receive large frames from the shmif device. > Well, maybe we should step back: what do you want to do? Is there > specific problem that the rump kernel stack refuses jumbo frames due to > if_mtu being too small? Did you set ETHERCAP_JUMBO_MTU and a 9000 mtu? > > I am talking mainly about checksum offload, which, if you read the > networking stack performance thread, will give a definite boost in > performance. Jumbo MTU is slightly different, since it's an ethernet > capability. I hadn't even considered it ;) > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > rumpkernel-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/rumpkernel-users ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
