On 2017年06月28日 12:01, Michael S. Tsirkin wrote:
On Wed, Jun 28, 2017 at 11:40:30AM +0800, Jason Wang wrote:
On 2017年06月28日 11:31, Michael S. Tsirkin wrote:
On Wed, Jun 28, 2017 at 10:45:18AM +0800, Jason Wang wrote:
On 2017年06月28日 10:17, Michael S. Tsirkin wrote:
On Wed, Jun 28, 2017 at 10:14:34AM +0800, Jason Wang wrote:
On 2017年06月28日 10:02, Michael S. Tsirkin wrote:
On Wed, Jun 28, 2017 at 09:54:03AM +0800, Jason Wang wrote:
We should allow csumed packet for small buffer, otherwise XDP_PASS
won't work correctly.
Fixes commit bb91accf2733 ("virtio-net: XDP support for small buffers")
Signed-off-by: Jason Wang<jasowang@xxxxxxxxxx>
The issue would be VIRTIO_NET_HDR_F_DATA_VALID might be set.
What do you think?
I think it's safe. For XDP_PASS, it work like in the past.
That's the part I don't get. With DATA_VALID csum in packet is wrong, XDP
tools assume it's value.
DATA_VALID is CHECKSUM_UNCESSARY on the host, and according to the comment
in skbuff.h
"
* The hardware you're dealing with doesn't calculate the full checksum
* (as in CHECKSUM_COMPLETE), but it does parse headers and verify
checksums
* for specific protocols. For such packets it will set
CHECKSUM_UNNECESSARY
* if their checksums are okay. skb->csum is still undefined in this case
* though. A driver or device must never modify the checksum field in the
* packet even if checksum is verified.
"
The csum is correct I believe?
Thanks
That's on input. But I think for tun it's output, where that is equivalent
to CHECKSUM_NONE
Yes, but the comment said:
"
CKSUM_NONE:
*
* The skb was already checksummed by the protocol, or a checksum is not
* required.
*
* CHECKSUM_UNNECESSARY:
*
* This has the same meaning on as CHECKSUM_NONE for checksum offload on
* output.
*
"
So still correct I think?
Thanks
Hmm maybe I mean NEEDS_CHECKSUM actually.
I'll need to re-read the spec.
Not sure this is an issue. But if it is, we can probably checksum the
packet before passing it to XDP. But it would be a little slow.
Thanks
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
