similar to: UFO - new version capable of S3 API?

I just installed glusterfs-swift 3.3.1 on a couple of Fedora 18 servers. This is based on swift 1.7.4 and has keystone in the config. I had experimented with the one based on swift 1.4.8 and tempauth and had some problems with it. The HOWTO I can find is still for the old one. Is there an updated one? I would also need to find some instructions on setting up keystone from scratch for

Hello everyone, I would like to ask a question regarding to disable UFO of virtio vNIC in my guest. I have read the document at https://libvirt.org/formatdomain.html *host* The csum, gso, tso4, tso6, ecn and ufo attributes with possible values on and off can be used to turn off host offloading options. By default, the supported offloads are enabled by QEMU. *Since 1.2.9 (QEMU only)* The

On Wed, 2014-11-19 at 11:14 +0200, Michael S. Tsirkin wrote: > On Thu, Oct 30, 2014 at 06:27:12PM +0000, Ben Hutchings wrote: > > IPv6 does not allow fragmentation by routers, so there is no > > fragmentation ID in the fixed header. UFO for IPv6 requires the ID to > > be passed separately, but there is no provision for this in the virtio > > net protocol. > >

On Wed, 2014-11-19 at 11:14 +0200, Michael S. Tsirkin wrote: > On Thu, Oct 30, 2014 at 06:27:12PM +0000, Ben Hutchings wrote: > > IPv6 does not allow fragmentation by routers, so there is no > > fragmentation ID in the fixed header. UFO for IPv6 requires the ID to > > be passed separately, but there is no provision for this in the virtio > > net protocol. > >

There are several ways that VMs can take advantage of UFO and get the host to do fragmentation for them: drivers/net/macvtap.c: gso_type = SKB_GSO_UDP; drivers/net/tun.c: skb_shinfo(skb)->gso_type = SKB_GSO_UDP; drivers/net/virtio_net.c: skb_shinfo(skb)->gso_type = SKB_GSO_UDP; Our implementation of UFO for IPv6 does: fptr =

There are several ways that VMs can take advantage of UFO and get the host to do fragmentation for them: drivers/net/macvtap.c: gso_type = SKB_GSO_UDP; drivers/net/tun.c: skb_shinfo(skb)->gso_type = SKB_GSO_UDP; drivers/net/virtio_net.c: skb_shinfo(skb)->gso_type = SKB_GSO_UDP; Our implementation of UFO for IPv6 does: fptr =

IPv6 does not allow fragmentation by routers, so there is no fragmentation ID in the fixed header. UFO for IPv6 requires the ID to be passed separately, but there is no provision for this in the virtio net protocol. Until recently our software implementation of UFO/IPv6 generated a new ID, but this was a bug. Now we will use ID=0 for any UFO/IPv6 packet passed through a tap, which is even

IPv6 does not allow fragmentation by routers, so there is no fragmentation ID in the fixed header. UFO for IPv6 requires the ID to be passed separately, but there is no provision for this in the virtio net protocol. Until recently our software implementation of UFO/IPv6 generated a new ID, but this was a bug. Now we will use ID=0 for any UFO/IPv6 packet passed through a tap, which is even

On 02/12/2014 07:59 PM, Michael S. Tsirkin wrote: > On Wed, Feb 12, 2014 at 01:43:28PM +0800, Jason Wang wrote: >> > We should alloc big buffers also when guest can receive UFO >> > pakcets. Otherwise the big packets will be truncated when mergeable rx >> > buffer is disabled. > Not truncated, they will be dropped. > Why dropped? We enable the ufo on tap0 if

On 02/12/2014 07:59 PM, Michael S. Tsirkin wrote: > On Wed, Feb 12, 2014 at 01:43:28PM +0800, Jason Wang wrote: >> > We should alloc big buffers also when guest can receive UFO >> > pakcets. Otherwise the big packets will be truncated when mergeable rx >> > buffer is disabled. > Not truncated, they will be dropped. > Why dropped? We enable the ufo on tap0 if

On Thu, 2014-12-18 at 00:28 -0500, Jason Wang wrote: > > ----- Original Message ----- > > UFO support in the kernel applies to both IPv4 and IPv6 protocols > > with the same device feature. However some devices may not be able > > to support one of the offloads. For this we split the UFO offload > > feature into 2 pieces. NETIF_F_UFO now controlls the IPv4 part

On Thu, 2014-12-18 at 00:28 -0500, Jason Wang wrote: > > ----- Original Message ----- > > UFO support in the kernel applies to both IPv4 and IPv6 protocols > > with the same device feature. However some devices may not be able > > to support one of the offloads. For this we split the UFO offload > > feature into 2 pieces. NETIF_F_UFO now controlls the IPv4 part

We should alloc big buffers also when guest can receive UFO pakcets to let the big packets be fit into guest rx buffer. Fixes 5c5167515d80f78f6bb538492c423adcae31ad65 (virtio-net: Allow UFO feature to be set and advertised.) Cc: Rusty Russell <rusty at rustcorp.com.au> Cc: Michael S. Tsirkin <mst at redhat.com> Cc: Sridhar Samudrala <sri at us.ibm.com> Signed-off-by: Jason Wang

We should alloc big buffers also when guest can receive UFO pakcets to let the big packets be fit into guest rx buffer. Fixes 5c5167515d80f78f6bb538492c423adcae31ad65 (virtio-net: Allow UFO feature to be set and advertised.) Cc: Rusty Russell <rusty at rustcorp.com.au> Cc: Michael S. Tsirkin <mst at redhat.com> Cc: Sridhar Samudrala <sri at us.ibm.com> Signed-off-by: Jason Wang

On Mon, 2015-01-26 at 09:37 -0500, Vladislav Yasevich wrote: > If the IPv6 fragment id has not been set and we perform > fragmentation due to UFO, select a new fragment id. > When we store the fragment id into skb_shinfo, set the bit > in the skb so we can re-use the selected id. > This preserves the behavior of UFO packets generated on the > host and solves the issue of id

On Mon, 2015-01-26 at 09:37 -0500, Vladislav Yasevich wrote: > If the IPv6 fragment id has not been set and we perform > fragmentation due to UFO, select a new fragment id. > When we store the fragment id into skb_shinfo, set the bit > in the skb so we can re-use the selected id. > This preserves the behavior of UFO packets generated on the > host and solves the issue of id

We should alloc big buffers also when guest can receive UFO pakcets. Otherwise the big packets will be truncated when mergeable rx buffer is disabled. Fixes 5c5167515d80f78f6bb538492c423adcae31ad65 (virtio-net: Allow UFO feature to be set and advertised.) Cc: Rusty Russell <rusty at rustcorp.com.au> Cc: Michael S. Tsirkin <mst at redhat.com> Cc: Sridhar Samudrala <sri at

We should alloc big buffers also when guest can receive UFO pakcets. Otherwise the big packets will be truncated when mergeable rx buffer is disabled. Fixes 5c5167515d80f78f6bb538492c423adcae31ad65 (virtio-net: Allow UFO feature to be set and advertised.) Cc: Rusty Russell <rusty at rustcorp.com.au> Cc: Michael S. Tsirkin <mst at redhat.com> Cc: Sridhar Samudrala <sri at

On Thu, Dec 25, 2014 at 2:59 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > On Wed, Dec 24, 2014 at 07:11:20PM +0100, Ben Hutchings wrote: >> On Thu, 2014-12-18 at 00:28 -0500, Jason Wang wrote: >> > >> > ----- Original Message ----- >> > > UFO support in the kernel applies to both IPv4 and IPv6 >> protocols >> > > with

On Thu, Dec 25, 2014 at 2:59 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > On Wed, Dec 24, 2014 at 07:11:20PM +0100, Ben Hutchings wrote: >> On Thu, 2014-12-18 at 00:28 -0500, Jason Wang wrote: >> > >> > ----- Original Message ----- >> > > UFO support in the kernel applies to both IPv4 and IPv6 >> protocols >> > > with