RE: [PATCH 7/7] [v5] drivers/virt: introduce Freescale hypervisormanagement driver
> > +enum fsl_hv_ioctl_cmd {
> > + FSL_HV_IOCTL_PARTITION_RESTART = _IOWR(0, 1, struct
fsl_hv_ioctl_restart),
...
> > +};
>
> Using a #define here is usually preferred because then you
> can use #ifdef in a user application to check if a given
> value has been assigned.
It is also possible to add:
#define FSL_HV_IOCTL_PARTITION_RESTART FSL_HV_IOCTL_PARTITION_RESTART
to have much the same effect.
But there are many cases where #defines are better.
I only tend to use enums when the constanst are beting generated
by the expansion of a #define.
> More importantly, the code you have chose (0) conflicts with
> existing drivers (frame buffer, scsi and wavefront among others).
> Please chose a free one and
> add it to Documentation/ioctl/ioctl-number.txt in the same patch.
It is rather a PITA that, when 'int' went from 16 to 32 bits, the
BSD people used the high 16 bits for size/flags rather than
using the extra bits to help make ioctl's unique.
Linux seems to have copied BSD here - rather than SYSV.
One problem with clashing ioctl commands is when systems like
NetBSD are running linux binaries and need to translate ioctl
buffers to/from native format. If the ioctl commands are
unique this can be done much more easily.
David
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH 7/7] [v5] drivers/virt: introduce Freescale hypervisor management driver
On Thu, Jun 09, 2011 at 10:33:07PM +0200, Arnd Bergmann wrote: > On Thursday 09 June 2011 22:18:28 Timur Tabi wrote: > > Ok, I was really hoping to avoid doing this. Like I said, binary > > compatibility > > is important, and changing the type will break my existing apps. Are you > > insisting that I pick a new number? > I definitely insist that you have a proper interface in the driver at the > time that it gets merged, and that probably includes a collision-free > ioctl code. This sort of stuff is one of the issues that should be being factored in to any decision not to publish and submit the kernel code - ABIs that haven't been reviewed upstream may well have this sort of issue. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH 7/7] [v4] drivers/virt: introduce Freescale hypervisor management driver
Randy Dunlap wrote: >> > I'm okay with that idea, except there's a consensus that drivers should be >> > in >> > drivers/. >> > > Like sound/ ? My understanding is that this is something that's considered broken and should be fixed, but I don't know what the holdup is. > but what makes it a "driver"? That's a good point. Ok, so maybe I don't have any really good answers here. :-) -- Timur Tabi Linux kernel developer at Freescale ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH 7/7] [v4] drivers/virt: introduce Freescale hypervisor management driver
Randy Dunlap wrote: > But it sounds like virt/ needs virt/host/ and virt/guest/ to me. I'm okay with that idea, except there's a consensus that drivers should be in drivers/. -- Timur Tabi Linux kernel developer at Freescale ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH 7/7] [v4] drivers/virt: introduce Freescale hypervisor management driver
On Friday 10 June 2011, Chris Metcalf wrote: > This still leaves open the question of what really should go in this new > directory. Is it just for drivers that manage/control the hypervisor? Or > is it also for drivers that just use the hypervisor to do I/O of some kind, > but aren't related to any other "family" of drivers, i.e., a driver that > would have been dumped in drivers/char or drivers/misc in the old days? > > My specific interest at the moment is the proposed tile-srom.c driver > (https://patchwork.kernel.org/patch/843892/), which uses a simple > hypervisor read/write API to access the portion of the SPI ROM used to hold > the boot stream for a TILE processor. I'd still put that driver in drivers/char for now, because it already contains similar drivers. We can probaby group them in a subdirectory of drivers/char at some point or move them out to a new directory. For your raw hcall passthrough driver, that would be something that should go into drivers/virt/ IMHO. Arnd ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: virtio scsi host draft specification, v3
> If requests are placed on arbitrary queues you'll inevitably run on > locking issues to ensure strict request ordering. > I would add here: > > If a device uses more than one queue it is the responsibility of the > device to ensure strict request ordering. Applied with s/device/guest/g. > Please do not rely in bus/target/lun here. These are leftovers from > parallel SCSI and do not have any meaning on modern SCSI > implementation (eg FC or SAS). Rephrase that to > > The lun field is the Logical Unit Number as defined in SAM. Ok. > > The status byte is written by the device to be the SCSI status > > code. > > ?? I doubt that exists. Make that: > > The status byte is written by the device to be the status code as > defined in SAM. Ok. > > The response byte is written by the device to be one of the > > following: > > > > - VIRTIO_SCSI_S_OK when the request was completed and the > > status byte > >is filled with a SCSI status code (not necessarily "GOOD"). > > > > - VIRTIO_SCSI_S_UNDERRUN if the content of the CDB requires > > transferring > >more data than is available in the data buffers. > > > > - VIRTIO_SCSI_S_ABORTED if the request was cancelled due to a > > reset > >or another task management function. > > > > - VIRTIO_SCSI_S_FAILURE for other host or guest error. In > > particular, > >if neither dataout nor datain is empty, and the > >VIRTIO_SCSI_F_INOUT > >feature has not been negotiated, the request will be > >immediately > >returned with a response equal to VIRTIO_SCSI_S_FAILURE. > > > And, of course: > > VIRTIO_SCSI_S_DISCONNECT if the request could not be processed due > to a communication failure (eg device was removed or could not be > reached). Ok. > This specification implies a strict one-to-one mapping between host > and target. IE there is no way of specifying more than one target > per host. Actually no, the intention is to use hierarchical LUNs to support more than one target per host. Paolo ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH 7/7] [v4] drivers/virt: introduce Freescale hypervisor management driver
On 6/9/2011 3:38 AM, Arnd Bergmann wrote: > On Thursday 09 June 2011 01:10:09 Randy Dunlap wrote: >> On Wed, 8 Jun 2011 17:45:54 -0500 Timur Tabi wrote: >> >>> Add the drivers/virt directory, which houses drivers that support >>> virtualization environments, and add the Freescale hypervisor management >>> driver. >> It can't go in linux/virt or linux/virt/fsl instead? why drivers/ ? >> >> or maybe linux/virt should be drivers/virt ? > See discussion for v2 of this patch. I suggested that drivers/firmware and > virt/ > as options, the counterarguments were that drivers/firmware is for passive > firmware as opposed to firmware that acts as a hypervisor, and that virt/ is > for the host side of hypervisors like kvm, not for guests. > > The driver in here most closely resembles the xen dom0 model, where a > priviledged guest controls other guests, but unlike xen there is a single > driver file, so there is no need to have drivers/fsl-hv directory just > for this one file. We do have a number of other hypervisors that fit in the > same category, so they can be added here later. This still leaves open the question of what really should go in this new directory. Is it just for drivers that manage/control the hypervisor? Or is it also for drivers that just use the hypervisor to do I/O of some kind, but aren't related to any other "family" of drivers, i.e., a driver that would have been dumped in drivers/char or drivers/misc in the old days? My specific interest at the moment is the proposed tile-srom.c driver (https://patchwork.kernel.org/patch/843892/), which uses a simple hypervisor read/write API to access the portion of the SPI ROM used to hold the boot stream for a TILE processor. -- Chris Metcalf, Tilera Corp. http://www.tilera.com ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: virtio scsi host draft specification, v3
On 06/07/2011 03:43 PM, Paolo Bonzini wrote:
> Hi all,
>
> after some preliminary discussion on the QEMU mailing list, I present a
> draft specification for a virtio-based SCSI host (controller, HBA, you
> name it).
>
> The virtio SCSI host is the basis of an alternative storage stack for
> KVM. This stack would overcome several limitations of the current
> solution, virtio-blk:
>
> 1) scalability limitations: virtio-blk-over-PCI puts a strong upper
> limit on the number of devices that can be added to a guest. Common
> configurations have a limit of ~30 devices. While this can be worked
> around by implementing a PCI-to-PCI bridge, or by using multifunction
> virtio-blk devices, these solutions either have not been implemented
> yet, or introduce management restrictions. On the other hand, the SCSI
> architecture is well known for its scalability and virtio-scsi supports
> advanced feature such as multiqueueing.
>
> 2) limited flexibility: virtio-blk does not support all possible storage
> scenarios. For example, it does not allow SCSI passthrough or persistent
> reservations. In principle, virtio-scsi provides anything that the
> underlying SCSI target (be it physical storage, iSCSI or the in-kernel
> target) supports.
>
> 3) limited extensibility: over the time, many features have been added
> to virtio-blk. Each such change requires modifications to the virtio
> specification, to the guest drivers, and to the device model in the
> host. The virtio-scsi spec has been written to follow SAM conventions,
> and exposing new features to the guest will only require changes to the
> host's SCSI target implementation.
>
>
> Comments are welcome.
>
> Paolo
>
> --->8 ---
>
>
> Virtio SCSI Host Device Spec
>
>
> The virtio SCSI host device groups together one or more simple virtual
> devices (ie. disk), and allows communicating to these devices using the
> SCSI protocol. An instance of the device represents a SCSI host with
> possibly many buses, targets and LUN attached.
>
> The virtio SCSI device services two kinds of requests:
>
> - command requests for a logical unit;
>
> - task management functions related to a logical unit, target or
> command.
>
> The device is also able to send out notifications about added
> and removed logical units.
>
> v1:
> First public version
>
> v2:
> Merged all virtqueues into one, removed separate TARGET fields
>
> v3:
> Added configuration information and reworked descriptor structure.
> Added back multiqueue on Avi's request, while still leaving TARGET
> fields out. Added dummy event and clarified some aspects of the
> event protocol. First version sent to a wider audience (linux-kernel
> and virtio lists).
>
> Configuration
> -
>
> Subsystem Device ID
> TBD
>
> Virtqueues
> 0:controlq
> 1:eventq
> 2..n:request queues
>
> Feature bits
> VIRTIO_SCSI_F_INOUT (0) - Whether a single request can include both
> read-only and write-only data buffers.
>
> Device configuration layout
> struct virtio_scsi_config {
> u32 num_queues;
> u32 event_info_size;
> u32 sense_size;
> u32 cdb_size;
> }
>
> num_queues is the total number of virtqueues exposed by the
> device. The driver is free to use only one request queue, or
> it can use more to achieve better performance.
>
> event_info_size is the maximum size that the device will fill
> for buffers that the driver places in the eventq. The
> driver should always put buffers at least of this size.
>
> sense_size is the maximum size of the sense data that the device
> will write. The default value is written by the device and
> will always be 96, but the driver can modify it.
>
> cdb_size is the maximum size of the CBD that the driver
> will write. The default value is written by the device and
> will always be 32, but the driver can likewise modify it.
>
> Device initialization
> -
>
> The initialization routine should first of all discover the device's
> virtqueues.
>
> The driver should then place at least a buffer in the eventq.
> Buffers returned by the device on the eventq may be referred
> to as "events" in the rest of the document.
>
> The driver can immediately issue requests (for example, INQUIRY or
> REPORT LUNS) or task management functions (for example, I_T RESET).
>
> Device operation: request queues
>
>
> The driver queues requests to an arbitrary request queue, and they are
> used by the device on that same queue.
>
What about request ordering?
If requests are placed on arbitrary queues you'll inevitably run on
locking issues to ensure strict request ordering.
I would add here:
If a device uses more than one queue it is the responsibility of the
device to ensure strict request ordering.
> Request
Re: virtio scsi host draft specification, v3
On 06/10/2011 02:14 PM, Stefan Hajnoczi wrote: > Paolo, I'll switch the Linux guest LLD and QEMU virtio-scsi skeleton > that I have to comply with the spec. Does this sound good or did you > want to write these from scratch? Why should I want to write things from scratch? :) Just send me again a pointer to your git tree, I'll make sure to add it as a remote this time (private mail will do). Thanks, Paolo ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: virtio scsi host draft specification, v3
On Fri, Jun 10, 2011 at 12:33 PM, Rusty Russell wrote: > On Thu, 09 Jun 2011 08:59:27 +0200, Paolo Bonzini wrote: >> On 06/09/2011 01:28 AM, Rusty Russell wrote: >> >> > after some preliminary discussion on the QEMU mailing list, I present a >> >> > draft specification for a virtio-based SCSI host (controller, HBA, you >> >> > name it). >> > >> > OK, I'm impressed. This is very well written and it doesn't make any of >> > the obvious mistakes wrt. virtio. >> >> Thanks very much, and thanks to those who corrected my early mistakes. >> >> > I assume you have an implementation, as well? >> >> Unfortunately not; "we're working on it", which means I should start in >> July when I come back from vacation. >> >> Do you prefer to wait for one before I make a patch to the LyX source? >> In the meanwhile, can you reserve a subsystem ID for me? >> >> Paolo > > Sure, you can have the next subsystem ID. > > It's a pain to patch once it's in LyX, so let's get the implementation > base on what you posted here an see how much it changes first... Paolo, I'll switch the Linux guest LLD and QEMU virtio-scsi skeleton that I have to comply with the spec. Does this sound good or did you want to write these from scratch? Stefan ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: virtio scsi host draft specification, v3
On Thu, 09 Jun 2011 08:59:27 +0200, Paolo Bonzini wrote: > On 06/09/2011 01:28 AM, Rusty Russell wrote: > >> > after some preliminary discussion on the QEMU mailing list, I present a > >> > draft specification for a virtio-based SCSI host (controller, HBA, you > >> > name it). > > > > OK, I'm impressed. This is very well written and it doesn't make any of > > the obvious mistakes wrt. virtio. > > Thanks very much, and thanks to those who corrected my early mistakes. > > > I assume you have an implementation, as well? > > Unfortunately not; "we're working on it", which means I should start in > July when I come back from vacation. > > Do you prefer to wait for one before I make a patch to the LyX source? > In the meanwhile, can you reserve a subsystem ID for me? > > Paolo Sure, you can have the next subsystem ID. It's a pain to patch once it's in LyX, so let's get the implementation base on what you posted here an see how much it changes first... Cheers, Rusty. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH] virtio_net: introduce VIRTIO_NET_HDR_F_DATA_VALID
On Fri, Jun 10, 2011 at 06:56:17PM +0800, Jason Wang wrote:
> There's no need for the guest to validate the checksum if it have been
> validated by host nics. So this patch introduces a new flag -
> VIRTIO_NET_HDR_F_DATA_VALID which is used to bypass the checksum
> examing in guest. The backend (tap/macvtap) may set this flag when
> met skbs with CHECKSUM_UNNECESSARY to save cpu utilization.
>
> No feature negotiation is needed as old driver just ignore this flag.
This wasn't required by the spec, but maybe it should be.
> Iperf shows 12%-30% performance improvement for UDP traffic. For TCP,
> when gro is on no difference as it produces skb with partial
> checksum. But when gro is disabled, 20% or even higher improvement
> could be measured by netperf.
>
> Signed-off-by: Jason Wang
Acked-by: Michael S. Tsirkin
> ---
> drivers/net/macvtap.c |2 ++
> drivers/net/tun.c |2 ++
> drivers/net/virtio_net.c |2 ++
> include/linux/virtio_net.h |1 +
> net/packet/af_packet.c |2 ++
> 5 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
> index 6696e56..ecee0fe 100644
> --- a/drivers/net/macvtap.c
> +++ b/drivers/net/macvtap.c
> @@ -508,6 +508,8 @@ static int macvtap_skb_to_vnet_hdr(const struct sk_buff
> *skb,
> vnet_hdr->flags = VIRTIO_NET_HDR_F_NEEDS_CSUM;
> vnet_hdr->csum_start = skb_checksum_start_offset(skb);
> vnet_hdr->csum_offset = skb->csum_offset;
> + } else if (skb->ip_summed == CHECKSUM_UNNECESSARY) {
> + vnet_hdr->flags = VIRTIO_NET_HDR_F_DATA_VALID;
> } /* else everything is zero */
>
> return 0;
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index 74e9405..f43fa45 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -788,6 +788,8 @@ static __inline__ ssize_t tun_put_user(struct tun_struct
> *tun,
> gso.flags = VIRTIO_NET_HDR_F_NEEDS_CSUM;
> gso.csum_start = skb_checksum_start_offset(skb);
> gso.csum_offset = skb->csum_offset;
> + } else if (skb->ip_summed == CHECKSUM_UNNECESSARY) {
> + gso.flags = VIRTIO_NET_HDR_F_DATA_VALID;
> } /* else everything is zero */
>
> if (unlikely(memcpy_toiovecend(iv, (void *)&gso, total,
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index f685324..be3686a 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -274,6 +274,8 @@ static void receive_buf(struct net_device *dev, void
> *buf, unsigned int len)
> hdr->hdr.csum_start,
> hdr->hdr.csum_offset))
> goto frame_err;
> + } else if (hdr->hdr.flags & VIRTIO_NET_HDR_F_DATA_VALID) {
> + skb->ip_summed = CHECKSUM_UNNECESSARY;
> }
>
> skb->protocol = eth_type_trans(skb, dev);
> diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
> index 136040b..970d5a2 100644
> --- a/include/linux/virtio_net.h
> +++ b/include/linux/virtio_net.h
> @@ -63,6 +63,7 @@ struct virtio_net_config {
> * specify GSO or CSUM features, you can simply ignore the header. */
> struct virtio_net_hdr {
> #define VIRTIO_NET_HDR_F_NEEDS_CSUM 1 // Use csum_start, csum_offset
> +#define VIRTIO_NET_HDR_F_DATA_VALID 2 // Csum is valid
> __u8 flags;
> #define VIRTIO_NET_HDR_GSO_NONE 0 // Not a GSO frame
> #define VIRTIO_NET_HDR_GSO_TCPV4 1 // GSO frame, IPv4 TCP (TSO)
> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> index c0c3cda..99ca471 100644
> --- a/net/packet/af_packet.c
> +++ b/net/packet/af_packet.c
> @@ -1681,6 +1681,8 @@ static int packet_recvmsg(struct kiocb *iocb, struct
> socket *sock,
> vnet_hdr.flags = VIRTIO_NET_HDR_F_NEEDS_CSUM;
> vnet_hdr.csum_start = skb_checksum_start_offset(skb);
> vnet_hdr.csum_offset = skb->csum_offset;
> + } else if (skb->ip_summed == CHECKSUM_UNNECESSARY) {
> + vnet_hdr.flags = VIRTIO_NET_HDR_F_DATA_VALID;
> } /* else everything is zero */
>
> err = memcpy_toiovec(msg->msg_iov, (void *)&vnet_hdr,
> --
> 1.7.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
[PATCH] virtio_net: introduce VIRTIO_NET_HDR_F_DATA_VALID
There's no need for the guest to validate the checksum if it have been
validated by host nics. So this patch introduces a new flag -
VIRTIO_NET_HDR_F_DATA_VALID which is used to bypass the checksum
examing in guest. The backend (tap/macvtap) may set this flag when
met skbs with CHECKSUM_UNNECESSARY to save cpu utilization.
No feature negotiation is needed as old driver just ignore this flag.
Iperf shows 12%-30% performance improvement for UDP traffic. For TCP,
when gro is on no difference as it produces skb with partial
checksum. But when gro is disabled, 20% or even higher improvement
could be measured by netperf.
Signed-off-by: Jason Wang
---
drivers/net/macvtap.c |2 ++
drivers/net/tun.c |2 ++
drivers/net/virtio_net.c |2 ++
include/linux/virtio_net.h |1 +
net/packet/af_packet.c |2 ++
5 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 6696e56..ecee0fe 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -508,6 +508,8 @@ static int macvtap_skb_to_vnet_hdr(const struct sk_buff
*skb,
vnet_hdr->flags = VIRTIO_NET_HDR_F_NEEDS_CSUM;
vnet_hdr->csum_start = skb_checksum_start_offset(skb);
vnet_hdr->csum_offset = skb->csum_offset;
+ } else if (skb->ip_summed == CHECKSUM_UNNECESSARY) {
+ vnet_hdr->flags = VIRTIO_NET_HDR_F_DATA_VALID;
} /* else everything is zero */
return 0;
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 74e9405..f43fa45 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -788,6 +788,8 @@ static __inline__ ssize_t tun_put_user(struct tun_struct
*tun,
gso.flags = VIRTIO_NET_HDR_F_NEEDS_CSUM;
gso.csum_start = skb_checksum_start_offset(skb);
gso.csum_offset = skb->csum_offset;
+ } else if (skb->ip_summed == CHECKSUM_UNNECESSARY) {
+ gso.flags = VIRTIO_NET_HDR_F_DATA_VALID;
} /* else everything is zero */
if (unlikely(memcpy_toiovecend(iv, (void *)&gso, total,
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index f685324..be3686a 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -274,6 +274,8 @@ static void receive_buf(struct net_device *dev, void *buf,
unsigned int len)
hdr->hdr.csum_start,
hdr->hdr.csum_offset))
goto frame_err;
+ } else if (hdr->hdr.flags & VIRTIO_NET_HDR_F_DATA_VALID) {
+ skb->ip_summed = CHECKSUM_UNNECESSARY;
}
skb->protocol = eth_type_trans(skb, dev);
diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
index 136040b..970d5a2 100644
--- a/include/linux/virtio_net.h
+++ b/include/linux/virtio_net.h
@@ -63,6 +63,7 @@ struct virtio_net_config {
* specify GSO or CSUM features, you can simply ignore the header. */
struct virtio_net_hdr {
#define VIRTIO_NET_HDR_F_NEEDS_CSUM1 // Use csum_start, csum_offset
+#define VIRTIO_NET_HDR_F_DATA_VALID2 // Csum is valid
__u8 flags;
#define VIRTIO_NET_HDR_GSO_NONE0 // Not a GSO frame
#define VIRTIO_NET_HDR_GSO_TCPV4 1 // GSO frame, IPv4 TCP (TSO)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index c0c3cda..99ca471 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1681,6 +1681,8 @@ static int packet_recvmsg(struct kiocb *iocb, struct
socket *sock,
vnet_hdr.flags = VIRTIO_NET_HDR_F_NEEDS_CSUM;
vnet_hdr.csum_start = skb_checksum_start_offset(skb);
vnet_hdr.csum_offset = skb->csum_offset;
+ } else if (skb->ip_summed == CHECKSUM_UNNECESSARY) {
+ vnet_hdr.flags = VIRTIO_NET_HDR_F_DATA_VALID;
} /* else everything is zero */
err = memcpy_toiovec(msg->msg_iov, (void *)&vnet_hdr,
--
1.7.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
