google / netstack

IPv4 and IPv6 userland network stack
Apache License 2.0
3.09k stars 279 forks source link

arm and windows support for fdbased link endpoint #6

Open Archieeeeee opened 6 years ago

Archieeeeee commented 6 years ago

From my understanding, fdbased link endpoint only supports linux,amd64 mainly because the fd IO is based on file rawfile_unsafe.go, if using "golang.org/x/sys/" package to implement fd IO operation, more OS/arch will be supported.

func Read(fd int, p []byte) (n int, err error) func Write(fd int, p []byte) (n int, err error) func SetNonblock(fd int, nonblocking bool) (err error)

iangudger commented 6 years ago

writev is used over write so that we don't have to re-allocate slices for performance reasons. In addition, because we know that the syscall won't block, we can use syscall.RawSyscall instead of syscall.Syscall for performance reasons as well.

interarticle commented 6 years ago

I think the use of SYS_WRITEV and RawSyscall are totally fine with respect to the title of the question, since these are supported by the built-in "syscall" library and will compile on GOARCH=arm64.

The question is why rawfile_unsafe.go needs to implement a custom assembly-version of blockingPoll(), which I think can be implemented instead as:

r1, _, err := syscall.Syscall(syscall.SYS_POLL, uintptr(fds), uintptr(nfds), uintptr(timeout))
return r1, err

The only difference I can tell between the custom blockingPoll() and the above version is the use of runtime·entersyscallblock instead of runtime·entersyscall before performing the syscall. Is there a strong performance/resource-consumption reason for using the former?

iangudger commented 6 years ago

runtime·entersyscallblock has significantly better performance than runtime·entersyscall.

I have made it so that syscall.Syscall is now used on non-AMD64 Linux: https://github.com/google/netstack/commit/a1b2fa9ec9564208078df110478d8d10865095c5

nl5887 commented 6 years ago

Seems syscall.SYS_POLL is missing on arm64, whereas it is available on arm. There is a syscall.SYS_PPOLL available on arm64, if we don't use sigmask the syscall SYS_PPOLL behaves the same as SYS_POLL.

if the sigmask argument is specified as NULL, then no signal mask
       manipulation is performed (and thus ppoll() differs from poll() only
       in the precision of the timeout argument).
nl5887 commented 6 years ago

Netstack is working now on arm, arm64, amd64 with this commit https://github.com/honeytrap/netstack/commit/dc4634714ee66442e442176fa93167adcce1cb27.

I'll work on Gerrit to submit the commit.

iangudger commented 6 years ago

@nl5887, any update?

tamird commented 4 years ago

This is all working now, I think. Can this be closed?