search for: crc32c

There''s no need to preserve this abstraction; it used to let us use hardware crc32c support directly, but libcrc32c now does that for us through the crypto API -- so we''re already using the Intel crc32c acceleration where appropriate, without having to do anything special. As is right and proper. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> --- fs/bt...

When writing to a newly created btrfs (vanilla 2.6.33-rc6, sparc64) the following messages are printed: [28617.650231] Kernel unaligned access at TPC[10101f18] btrfs_csum_final+0x38/0x60 [btrfs] [28617.745783] Kernel unaligned access at TPC[10101f18] btrfs_csum_final+0x38/0x60 [btrfs] [28654.589492] Kernel unaligned access at TPC[10101f18] btrfs_csum_final+0x38/0x60 [btrfs] [28654.685036] Kernel

...e SCTP is excluded with the stardard checksum and requires a little bit extra. This series proposes VIRTIO_NET_F_SCTP_CSUM feature bit. As the "little bit extra", the kernel uses a new bit in the skb (skb->csum_not_inet) to determine whether to use standard inet checksum or the SCTP CRC32c checksum. This bit has to be communicated between the host and the guest. This bit is carried in the vnet header. Tap and macvtap support is added through an extra feature for the TUNSETOFFLOAD ioctl. Additionally macvtap will no correctly do sctp checksumming if the receive doesn't support...

...e SCTP is excluded with the stardard checksum and requires a little bit extra. This series proposes VIRTIO_NET_F_SCTP_CSUM feature bit. As the "little bit extra", the kernel uses a new bit in the skb (skb->csum_not_inet) to determine whether to use standard inet checksum or the SCTP CRC32c checksum. This bit has to be communicated between the host and the guest. This bit is carried in the vnet header. Tap and macvtap support is added through an extra feature for the TUNSETOFFLOAD ioctl. Additionally macvtap will no correctly do sctp checksumming if the receive doesn't support...

...> > > mirrors the skb->csum_not_inet flag. This flags is used to indicate > > > that is this an SCTP packet that needs its checksum computed by the > > > lower layer. In this case, the lower layer is the host hypervisor or > > > possibly HW nic that supporst CRC32c offload. > > > > > > In the case that GUEST feature bit is flag, it will be possible to > > > receive a virtio_net header with this bit set, which will set the > > > corresponding skb bit. SCTP protocol will be updated to correctly > > > deal with it. &...

...line dedup for Btrfs. It''s working quite well so I think it can be more widely tested. There are two ways to use it 1) Compatible mode - this is a bit slower but will handle being used by older kernels. We use the csum tree to find duplicate blocks. Since it is relatively easy to have crc32c collisions this also involves reading the block from disk and doing a memcmp with the block we want to write to verify it has the same data. This is way slow but hey, no incompat flag! 2) Incompatible mode - so this is the way you probably want to use it if you don''t care about being abl...

On Thu, Jun 12, 2014 at 05:08:37PM +0530, abhishek jain wrote: > Hi Rich > > I have all the virtio modules available in the kernel but I'm getting the > same result . It doesn't appear to be using any kernel modules. I would have expected to see output such as this: supermin: internal insmod virtio.ko It seems as if you might not be setting SUPERMIN_MODULES; or maybe you

...e SCTP is excluded with the stardard checksum and requires a little bit extra. This series proposes VIRTIO_NET_F_SCTP_CSUM feature bit. As the "little bit extra", the kernel uses a new bit in the skb (skb->csum_not_inet) to determine whether to use standard inet checksum or the SCTP CRC32c checksum. This bit has to be communicated between the host and the guest. This bit is carried in the vnet header. Tap and macvtap support is added through an extra feature for the TUNSETOFFLOAD ioctl. Additionally macvtap will no correctly do sctp checksumming if the receive doesn't support...

On Tue, May 01, 2018 at 10:07:38PM -0400, Vladislav Yasevich wrote: > Since we now have support for software CRC32c offload, turn it on > for macvlan and macvtap devices so that guests can take advantage > of offload SCTP checksums to the host or host hardware. > > Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> > --- > drivers/net/macvlan.c | 5 +++-- > drivers/net/tap.c...

On Tue, May 01, 2018 at 10:07:38PM -0400, Vladislav Yasevich wrote: > Since we now have support for software CRC32c offload, turn it on > for macvlan and macvtap devices so that guests can take advantage > of offload SCTP checksums to the host or host hardware. > > Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> > --- > drivers/net/macvlan.c | 5 +++-- > drivers/net/tap.c...

...ash tables configured (established 4096 bind 2048) TCP reno registered audit: initializing netlink socket (disabled) type=2000 audit(1248432960.421:1): initialized VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) Initializing Cryptographic API alg: No test for crc32c (crc32c-generic) ksign: Installing public key data Loading keyring - Added public key 296070D98CC762AE - User ID: CentOS (Kernel Module GPG key) io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) pci_hotplug: PCI...

...h tables configured (established 262144 bind 65536) TCP reno registered audit: initializing netlink socket (disabled) type=2000 audit(1402907331.494:1): initialized VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 512 (order 0, 4096 bytes) Initializing Cryptographic API alg: No test for crc32c (crc32c-generic) ksign: Installing public key data Loading keyring - Added public key 691B840A64868995 - User ID: CentOS (Kernel Module GPG key) io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) pci_hotplug: PCI...

...failed BUG: unable to handle kernel paging request at ffffffcd IP: [<c01b5f36>] fput+0x6/0x30 *pde = 00575067 *pte = 00000000 Oops: 0002 [#1] SMP last sysfs file: /sys/block/sda/removable Modules linked in: kqemu sha256_generic aes_i586 aes_generic cbc usb_storage dm_crypt btrfs zlib_deflate crc32c libcrc32c tun radeon drm usblp af_packet ipv6 binfmt_misc loop dm_mirror dm_region_hash dm_log dm_mod cpufreq_ondemand cpufreq_conservative cpufreq_powersave p4_clockmod freq_table speedstep_lib snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device...

...rt between the hypervisor > and the guest. > > The signalling to the guest that an alternate checksum needs to > be used is done via a new flag in the virtio_net_hdr. If the > flag is set, the host will know to perform an alternate checksum > calculation, which right now is only CRC32c. > > Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> > --- > drivers/net/virtio_net.c | 11 ++++++++--- > include/linux/virtio_net.h | 6 ++++++ > include/uapi/linux/virtio_net.h | 2 ++ > 3 files changed, 16 insertions(+), 3 deletions(-) >...

...rt between the hypervisor > and the guest. > > The signalling to the guest that an alternate checksum needs to > be used is done via a new flag in the virtio_net_hdr. If the > flag is set, the host will know to perform an alternate checksum > calculation, which right now is only CRC32c. > > Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> > --- > drivers/net/virtio_net.c | 11 ++++++++--- > include/linux/virtio_net.h | 6 ++++++ > include/uapi/linux/virtio_net.h | 2 ++ > 3 files changed, 16 insertions(+), 3 deletions(-) >...

...specifying a base architecture per file, when you'd rather pull that from the main march. (plus you're putting arch specific special cases in your build config, which isn't great either) >>> As a result, one of the "-march" options either specified by Chrome OS or crc32c build has to lose the race as there was no other way to specify crc+crypto additively. Is this not deterministic? I would assume either Chrome OS always wins or crc32c always wins. Tell me if I'm wrong. Thanks, David Spickett. ________________________________ From: Manoj Gupta <manojg...

...uint8_t *data = d; + + return read16(data) + (1 << 16) * (uint32_t)read16(data + 2); +} + +uint64_t +read64(const void *d) +{ + const uint8_t *data = d; + + return read32(data) + (1ull << 32) * (uint64_t)read32(data + 2); +} + +/* + * Extracted from the linux kernel source code, lib/libcrc32c.c. + * + */ +static const uint32_t crc32c_table[256] = { + 0x00000000L, 0xF26B8303L, 0xE13B70F7L, 0x1350F3F4L, + 0xC79A971FL, 0x35F1141CL, 0x26A1E7E8L, 0xD4CA64EBL, + 0x8AD958CFL, 0x78B2DBCCL, 0x6BE22838L, 0x9989AB3BL, + 0x4D43CFD0L, 0xBF284CD3L, 0xAC78BF27L, 0x5E133C24L, + 0x105EC76FL, 0xE235446C...

...t fails like so: gcc -Wp,-MMD,./.btrfsctl.o.d,-MT,btrfsctl.o -Wall -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -g -Werror -Os -c btrfsctl.c gcc -g -Werror -Os -o btrfsctl btrfsctl.o ctree.o disk-io.o radix-tree.o extent-tree.o print-tree.o root-tree.o dir-item.o file-item.o inode-item.o inode-map.o crc32c.o rbtree.o extent-cache.o extent_io.o volumes.o utils.o btrfs-list.o btrfslabel.o -luuid ls mkfs.c mkfs.c gcc -Wp,-MMD,./.mkfs.o.d,-MT,mkfs.o -Wall -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -g -Werror -Os -c mkfs.c mkfs.c:39:24: fatal error: attr/xattr.h: No such file or directory compilation ter...

Hi Konrad I encountered a bug when trying to bring offline a cpu then online it again in HVM. As I''m not very familiar with HVM stuffs I cannot come up with a quick fix. The HVM DomU is configured with 4 vcpus. After booting into command prompt, I do following operations. # echo 0 > /sys/devices/system/cpu/cpu3/online # echo 1 > /sys/devices/system/cpu/cpu3/online With

After a reorganisation of patches, and sending a bunch of them to Chris, I''ve also updated the integration branch to match that. It''s available from: http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ integration-20110630 The shortlog of 17 patches in this branch beyond the ones I''ve sent to Chris is below. Hugo. Andreas Philipp (1): print parent