search for: af_packets

Hello I am on Athlon 1Gz, kernel 2.4.8. I was running a perl pgm with a lot of disk access, deletions and symlinks creations... Maybe It is due to the kernel version. Could you please inform me if must upgrade to a more recent kernel ? Thanks a lot the kernel logs are : in errors logs Oct 18 17:31:16 tadorne kernel: Assertion failure in journal_revoke_Rb5884a32() at revoke.c:307:

On Wed, Sep 23, 2015 at 07:45:08PM +0100, David Woodhouse 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. > > Since virtio_legacy_is_little_endian() is a very long identifier, > define a VIO_LE macro and use

On Wed, Sep 23, 2015 at 07:45:08PM +0100, David Woodhouse 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. > > Since virtio_legacy_is_little_endian() is a very long identifier, > define a VIO_LE macro and use

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

On Thu, Sep 24, 2015 at 09:25:45AM +0200, Greg Kurz wrote: > 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

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 +-

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.

Userspace virtio server has the following hack so guests rely on it, and we have to replicate it, too: Use port number to detect incoming IPv4 DHCP response packets, and fill in the checksum for these. The issue we are solving is that on linux guests, some apps that use recvmsg with AF_PACKET sockets, don't know how to handle CHECKSUM_PARTIAL; The interface to return the relevant information

Userspace virtio server has the following hack so guests rely on it, and we have to replicate it, too: Use port number to detect incoming IPv4 DHCP response packets, and fill in the checksum for these. The issue we are solving is that on linux guests, some apps that use recvmsg with AF_PACKET sockets, don't know how to handle CHECKSUM_PARTIAL; The interface to return the relevant information

Bug report follows. Please CC me if you want me to read the reply, as I'm not subscribed to ext3-users. [1.] One line summary of the problem: Ext3 has just causing filesystem corruption which required fsck to fix. [2.] Full description of the problem/report: I just had my machine lock up with an ext3 oops, preceeded by a bunch of error messages in the logs. On rebooting, after replaying the

..._TCP_ECN; if (vnet_hdr.gso_size == 0) goto out_unlock; } we used to report UFO6 as SKB_GSO_UDP, we probably should keep doing this, with your patch we select the goto out_unlock path. > It is true that with this series af_packets now can't do IPv6 UFO > since there is no VIRTIO_NET_HDR_GSO_UDPV6 yet. What do you mean by "do". Are we talking about sending or receiving packets? You seem to conflate the two. We always discarded ID on RX. For tun, this is xmit, so just by saying "this device can not do...

..._TCP_ECN; if (vnet_hdr.gso_size == 0) goto out_unlock; } we used to report UFO6 as SKB_GSO_UDP, we probably should keep doing this, with your patch we select the goto out_unlock path. > It is true that with this series af_packets now can't do IPv6 UFO > since there is no VIRTIO_NET_HDR_GSO_UDPV6 yet. What do you mean by "do". Are we talking about sending or receiving packets? You seem to conflate the two. We always discarded ID on RX. For tun, this is xmit, so just by saying "this device can not do...

On Fri, Apr 14, 2017 at 05:42:58AM +0300, Michael S. Tsirkin wrote: > Hi all, I wanted to raise the question of similarities between virtio > and new zero copy af_packet interfaces. > > First I would like to mention that virtio device development isn't spec > limited - spec is there to help interoperability and add peace of mind > for people worried about IPR. > > So

On Fri, Apr 14, 2017 at 05:42:58AM +0300, Michael S. Tsirkin wrote: > Hi all, I wanted to raise the question of similarities between virtio > and new zero copy af_packet interfaces. > > First I would like to mention that virtio device development isn't spec > limited - spec is there to help interoperability and add peace of mind > for people worried about IPR. > > So

From: David Woodhouse <dwmw2 at infradead.org> Date: Wed, 23 Sep 2015 15:44:30 +0100 > +#define VIO_LE virtio_legacy_is_little_endian() When you define a shorthand macro, the defines to a function call, make the macro have parenthesis too.

On Tue, Aug 01, 2017 at 08:54:27PM -0700, Steven Luong wrote: > * Descriptor ring: > > Guest adds descriptors with unique index values and DESC_HW set in flags. > Host overwrites used descriptors with correct len, index, and DESC_HW > clear.? Flags are always set/cleared last. > > #define DESC_HW 0x0080 > > struct desc { > ? ? ? ? __le64

From: David Woodhouse <dwmw2 at infradead.org> Date: Wed, 23 Sep 2015 15:44:30 +0100 > +#define VIO_LE virtio_legacy_is_little_endian() When you define a shorthand macro, the defines to a function call, make the macro have parenthesis too.