Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Zero Copy Rx packet buffering #4

Open
soypat opened this issue Dec 9, 2023 · 0 comments
Open

Zero Copy Rx packet buffering #4

soypat opened this issue Dec 9, 2023 · 0 comments

Comments

@soypat
Copy link
Owner

soypat commented Dec 9, 2023

Seqs today

  1. eth package which represents packet headers as structs with fields..
  2. Above implies that when packets are parsed the header bytes are copied onto the stack
  3. The stack.TCPPacket and stack.UDPPacket types are more resource intensive than really necessary since they require copying IP/TCP options and payload

While point 3 can be easily fixed by just passing around the buffer, removing copying in point 2 is not as easy and would require the creation of a new package.

zc package

A Zero Copy package is proposed to reduce sopying during packet processing and alleviating stack growth.
This package would likely have a larger scope than the current eth package. Below are some thoughts/suggestions on types to start a conversation:

  1. A base Buffer type which has a backing []byte type. This type offers no guarantees of what is contained inside the buffer. It offers methods such as

    func (b Buffer) Ethernet() (EthernetBuffer, error)
    func (b Buffer) IPv4() (IPv4Buffer, error)
  2. These EthernetBuffer and IPv4Buffer types are guaranteed to contain valid buffer information up to where their header ends. All these really need is a single uintptr or unsafe.Pointer backing type. Their methods would be roughly equivalent to the fields of the eth types today and would use unsafe package to extract the data. Methods should check for nullity and panic if pointer is null, which means the Ethernet/IPv4 method returned an error and the error was ignored before trying to extract data. Maybe as a first approximation the backing type can be a byte slice and this be changed in the future to use thin pointers.

  3. TCP/UDP: TCPBuffer and UDPBuffer types, which can be returned by IPv4Buffer (along with an error since buffer length may not be sufficient). The TCPBuffer type would need to be a semi-fat pointer since it has no information on the end of the payload. The UDPBuffer type could do with only a thin pointer.

    func (ipb IPv4Buffer) TCP() (TCPBuffer, error)
    func (ipb IPv4Buffer) UDP() (UDPBuffer, error)

Development

I think the above description is enough to start writing and testing the package out. The first step I'd imagine would be to start with a partial/complete zc package implementation and try replacing the packet parsing in PortStack.RecvEth method and benchmark speed improvements to see if Zero Copy benefits are really worth it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant