You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems that in #23, support for vectored operations has been removed.
Is there any particular reason for this move? I know there has been an issue with vectored operations being much slower than standard ones (at least in my testing), but I've never been able to pinpoint the source of the issue. However, it would be useful to have if this project ever got to implementing GSO/GRO.
The text was updated successfully, but these errors were encountered:
Is there any particular reason for this move? I know there has been an issue with vectored operations being much slower than standard ones (at least in my testing), but I've never been able to pinpoint the source of the issue.
The vectored operations make the implementation of the unified packets delivered from/to tun2 a bit tricky. Moreover, the default implementations of read_vectored and write_vectored in the standard library are sufficient to cover most cases, so, with a trade-off, we removed the customed vectored operations.
However, it would be useful to have if this project ever got to implementing GSO/GRO.
We may implement this function if more details could be provided, of course, a PR is appreciated.
Seems wireguard-go does not need vectored operations to achieve high throughput. They are also not required for GSO/GRO, so I'm thinking this might be closed.
It seems that in #23, support for vectored operations has been removed.
Is there any particular reason for this move? I know there has been an issue with vectored operations being much slower than standard ones (at least in my testing), but I've never been able to pinpoint the source of the issue. However, it would be useful to have if this project ever got to implementing GSO/GRO.
The text was updated successfully, but these errors were encountered: