search for: checksum_unnecessari

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.

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.

Commits: fd2a0437dc33 virtio_net: introduce virtio_net_hdr_{from,to}_skb e858fae2b0b8 virtio_net: use common code for virtio_net_hdr and skb GSO conversion introduced a subtle (but unexplained) difference in how virtio_net flags are derived from skb->ip_summed fields on transmit from the guest to the host/backend. Prior to the patches the flags would be set to VIRTIO_NET_HDR_F_NEEDS_CSUM if

Commits: fd2a0437dc33 virtio_net: introduce virtio_net_hdr_{from,to}_skb e858fae2b0b8 virtio_net: use common code for virtio_net_hdr and skb GSO conversion introduced a subtle (but unexplained) difference in how virtio_net flags are derived from skb->ip_summed fields on transmit from the guest to the host/backend. Prior to the patches the flags would be set to VIRTIO_NET_HDR_F_NEEDS_CSUM if

On Tue, Jan 17, 2017 at 04:20:49PM +0000, Rolf Neugebauer wrote: > Commits: > > fd2a0437dc33 virtio_net: introduce virtio_net_hdr_{from,to}_skb > e858fae2b0b8 virtio_net: use common code for virtio_net_hdr and skb > GSO conversion > > introduced a subtle (but unexplained) difference in how virtio_net > flags are derived from skb->ip_summed fields on transmit from the

Another checksum offload problem was reported on xen-users, when using a domU as a firewall: http://lists.xensource.com/archives/html/xen-users/2006-04/msg01150.html It also fails without VLANs. The path from dom0->domU with ip_summed==CHECKSUM_HW/proto_csum_blank==1 is broken. - skb_checksum_setup() assumes that a checksum will definitely be calculated in dev_queue_xmit(), but the

On Wed, Jun 28, 2017 at 08:05:06PM +0800, Jason Wang wrote: > > > 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,

On Wed, Jun 28, 2017 at 08:05:06PM +0800, Jason Wang wrote: > > > 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,

Hi, This patches introduce virtio_net_hdr_{from,to}_skb functions for conversion of GSO information between skb and virtio_net_hdr. Mike Rapoport (6): virtio_net: add _UAPI prefix to virtio_net header guards virtio_net: introduce virtio_net_hdr_{from,to}_skb macvtap: use common code for virtio_net_hdr and skb GSO conversion tuntap: use common code for virtio_net_hdr and skb GSO

Hi, This patches introduce virtio_net_hdr_{from,to}_skb functions for conversion of GSO information between skb and virtio_net_hdr. Mike Rapoport (6): virtio_net: add _UAPI prefix to virtio_net header guards virtio_net: introduce virtio_net_hdr_{from,to}_skb macvtap: use common code for virtio_net_hdr and skb GSO conversion tuntap: use common code for virtio_net_hdr and skb GSO

On 2017?07?04? 01:03, Michael S. Tsirkin wrote: > On Wed, Jun 28, 2017 at 08:05:06PM +0800, Jason Wang wrote: >> >> 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:

Hello, I''m trying to setup Xen on a machine with 2 physical network devices using linux bonding without success. I haven''t received any answer on my question on xen-users, the only discussion on this seems to be at http://lists.xensource.com/archives/html/xen-devel/2005-10/msg01174.html Could someone shed some light on state/ plans regarding Xen and bonding? Regards --

Commit 501db511397f ("virtio: don't set VIRTIO_NET_HDR_F_DATA_VALID on xmit") in fact disables VIRTIO_HDR_F_DATA_VALID on receiving path too, fixing this by adding a hint (has_data_valid) and set it only on the receiving path. Cc: Rolf Neugebauer <rolf.neugebauer at docker.com> Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/net/macvtap.c | 2 +-

Commit 501db511397f ("virtio: don't set VIRTIO_NET_HDR_F_DATA_VALID on xmit") in fact disables VIRTIO_HDR_F_DATA_VALID on receiving path too, fixing this by adding a hint (has_data_valid) and set it only on the receiving path. Cc: Rolf Neugebauer <rolf.neugebauer at docker.com> Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/net/macvtap.c | 2 +-

The virtio_net driver currently deals with different versions and types of virtio net headers, such as virtio_net_hdr_mrg_rxbuf, virtio_net_hdr_v1_hash, etc. Due to these variations, the code relies on multiple type casts to convert memory between different structures, potentially leading to bugs when there are changes in these structures. Introduces the "struct skb_vnet_common_hdr" as

On Wed, 23 Sep 2015 19:45:08 +0100 David Woodhouse <dwmw2 at infradead.org> wrote: > Commit 7d82410950aa ("virtio: add explicit big-endian support to memory > accessors") accidentally changed the virtio_net header used by > AF_PACKET with PACKET_VNET_HDR from host-endian to big-endian. > Hi David, Oops my bad... I obviously overlooked this one when adding

On Wed, 23 Sep 2015 19:45:08 +0100 David Woodhouse <dwmw2 at infradead.org> wrote: > Commit 7d82410950aa ("virtio: add explicit big-endian support to memory > accessors") accidentally changed the virtio_net header used by > AF_PACKET with PACKET_VNET_HDR from host-endian to big-endian. > Hi David, Oops my bad... I obviously overlooked this one when adding

The virtio_net driver currently deals with different versions and types of virtio net headers, such as virtio_net_hdr_mrg_rxbuf, virtio_net_hdr_v1_hash, etc. Due to these variations, the code relies on multiple type casts to convert memory between different structures, potentially leading to bugs when there are changes in these structures. Introduces the "struct skb_vnet_common_hdr" as

On Thu, Aug 17, 2023 at 5:52?PM Feng Liu <feliu at nvidia.com> wrote: > > > > On 2023-08-17 p.m.2:26, Willem de Bruijn wrote: > > External email: Use caution opening links or attachments > > > > > > On Thu, Aug 17, 2023 at 11:20?AM Feng Liu <feliu at nvidia.com> wrote: > >> > >> The virtio_net driver currently deals with different

On Thu, Aug 17, 2023 at 11:20?AM Feng Liu <feliu at nvidia.com> wrote: > > The virtio_net driver currently deals with different versions and types > of virtio net headers, such as virtio_net_hdr_mrg_rxbuf, > virtio_net_hdr_v1_hash, etc. Due to these variations, the code relies > on multiple type casts to convert memory between different structures, > potentially leading to