search for: hard_header_len

..., now it can report > cisco-hdlc device as Ethernet (with cisco-compatible bridge > encapsulation). > But I have one problem: > hdlc_cisco must add 4-byte header in hard_start_xmit (as > long as no one call hard_header. But I have no space, as > long as bridge's interface have hard_header_len = 0.... > So' I have to make a COPY os skbuff, instead of cloning if > I'm the only user.... > > When I add hard_header_len = 4, it stopped work even on > Ethernet. > Is it hard to make bridge working with hard_header_len != 0 > (It's necessary for Ethernet in (cis...

...cisco-hdlc device as Ethernet (with cisco-compatible bridge > > encapsulation). > > But I have one problem: > > hdlc_cisco must add 4-byte header in hard_start_xmit (as > > long as no one call hard_header. But I have no space, as > > long as bridge's interface have hard_header_len = 0.... > > So' I have to make a COPY os skbuff, instead of cloning if > > I'm the only user.... > > > > When I add hard_header_len = 4, it stopped work even on > > Ethernet. > > Is it hard to make bridge working with hard_header_len != 0 > > (It...

On Sun, 27 Jun 2004 15:43:30 +0700 <arkady-parabel@ngs.ru> wrote: > Hi. > > I'm using a powerpc-based board (CPU - Motorolla 82855, 50 > Mhz) with 32 Mb of RAM, Big Endian. > Linux kernel - 2.4.22, bridge - statically linked & as a > module > brctl - 0.9.6 > Ethernet - fec (arch/ppc/8xx_io/fec.c) > All this was compiled with gcc version 3.2.2 20030217

...> > Because the RING_SIZE < 4 case requires much more adjustments. > > * We may need to squeeze the virtio header into the headroom. > * We may need to squeeze the GSO header into the headroom, or block the features. We alread do this though no? I think we'll need to tweak hard_header_len to guarantee it's there as opposed to needed_headroom ... > * At the moment, without NETIF_F_SG, we can receive a skb with 2 segments, we may need to reduce it to 1. You are saying clearing NETIF_F_SG does not guarantee a linear skb? > * We may need to change all the control commands,...

...RX_HANDLER_EXACT; + + skb->dev = dev; + + return RX_HANDLER_ANOTHER; +} + +static void net_failover_compute_features(struct net_device *dev) +{ + u32 vlan_features = FAILOVER_VLAN_FEATURES & NETIF_F_ALL_FOR_ALL; + netdev_features_t enc_features = FAILOVER_ENC_FEATURES; + unsigned short max_hard_header_len = ETH_HLEN; + unsigned int dst_release_flag = IFF_XMIT_DST_RELEASE | + IFF_XMIT_DST_RELEASE_PERM; + struct net_failover_info *nfo_info = netdev_priv(dev); + struct net_device *primary_dev, *standby_dev; + + primary_dev = rcu_dereference(nfo_info->primary_dev); + if (primary_dev) { + vlan_fe...

...S (NETIF_F_HW_CSUM | NETIF_F_SG | \ + NETIF_F_RXCSUM | NETIF_F_ALL_TSO) + +static void net_failover_compute_features(struct net_device *dev) +{ + u32 vlan_features = FAILOVER_VLAN_FEATURES & NETIF_F_ALL_FOR_ALL; + netdev_features_t enc_features = FAILOVER_ENC_FEATURES; + unsigned short max_hard_header_len = ETH_HLEN; + unsigned int dst_release_flag = IFF_XMIT_DST_RELEASE | + IFF_XMIT_DST_RELEASE_PERM; + struct net_failover_info *nfo_info = netdev_priv(dev); + struct net_device *primary_dev, *standby_dev; + + primary_dev = rcu_dereference(nfo_info->primary_dev); + if (primary_dev) { + vlan_fe...

...p; > + !((unsigned long)skb->data & (__alignof__(*hdr) - 1)) && > + !skb_header_cloned(skb) && skb_headroom(skb) >= hdr_len; Idle thought: how often does this fail? Would it suck if we copied headers which didn't let us prepend data? Or could we bump dev->hard_header_len appropriately? Thanks, Rusty.

> > This patchset follows a discussion in the mailing list [1]. > > > > This fixes only part of the bug, rings with less than 4 entries won't > > work. > > Why the difference? > Because the RING_SIZE < 4 case requires much more adjustments. * We may need to squeeze the virtio header into the headroom. * We may need to squeeze the GSO header into the

Dear Sir, I was trying to install bridge as we are installing scps gateway in our testbed.This requires us to install the bridge. Our Linux version is 2.4.18 ~3 and we are using redhat 7.2 Please let me know which is the bridge I should install and how to configure it. Before configuring the bridge what I should check in my configuration. Thanks for your time, Sincerely Rama ===== I hear

This is another update based on feedback from MST and Stephen on the last patchset. Hopefully this series can be integrated and any further enhancements can be made on top of this patchset. v8: - Made the failover managment routines more robust by updating the feature bits/other fields in the failover netdev when slave netdevs are registered/unregistered. (mst) - added support for handling

The main motivation for this patch is to enable cloud service providers to provide an accelerated datapath to virtio-net enabled VMs in a transparent manner with no/minimal guest userspace changes. This also enables hypervisor controlled live migration to be supported with VMs that have direct attached SR-IOV VF devices. Patch 1 introduces a new feature bit VIRTIO_NET_F_STANDBY that can be used

For small packets we can simplify xmit processing by linearizing buffers with the header: most packets seem to have enough head room we can use for this purpose. Since some older hypervisors (e.g. qemu before version 1.5) required that header is the first s/g element, we need a feature bit for this. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- This is a repost of my old

For small packets we can simplify xmit processing by linearizing buffers with the header: most packets seem to have enough head room we can use for this purpose. Since some older hypervisors (e.g. qemu before version 1.5) required that header is the first s/g element, we need a feature bit for this. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- This is a repost of my old

The main motivation for this patch is to enable cloud service providers to provide an accelerated datapath to virtio-net enabled VMs in a transparent manner with no/minimal guest userspace changes. This also enables hypervisor controlled live migration to be supported with VMs that have direct attached SR-IOV VF devices. Patch 1 introduces a failover module that provides a generic interface for

The main motivation for this patch is to enable cloud service providers to provide an accelerated datapath to virtio-net enabled VMs in a transparent manner with no/minimal guest userspace changes. This also enables hypervisor controlled live migration to be supported with VMs that have direct attached SR-IOV VF devices. Patch 1 introduces a failover module that provides a generic interface for

Second version, all feedback so far addressed, thanks for the help and interest! The patch to iproute2 has not changed, so I'm not including it this time. Patch 4/4 (the netlink interface) is basically unchanged as well but included for completeness. The other changes have moved forward a bit, to the point where I find them a lot cleaner and am more confident in the code being ready for

Second version, all feedback so far addressed, thanks for the help and interest! The patch to iproute2 has not changed, so I'm not including it this time. Patch 4/4 (the netlink interface) is basically unchanged as well but included for completeness. The other changes have moved forward a bit, to the point where I find them a lot cleaner and am more confident in the code being ready for

Second version, all feedback so far addressed, thanks for the help and interest! The patch to iproute2 has not changed, so I'm not including it this time. Patch 4/4 (the netlink interface) is basically unchanged as well but included for completeness. The other changes have moved forward a bit, to the point where I find them a lot cleaner and am more confident in the code being ready for

Not many changes this time, just integrated a bug fix and all the coding style feedback from Eric Dumazet and Patrick McHardy. I'll keep the patch for network namespaces on the tx path out of this series for now, because the discussion is still ongoing and it addresses an unrelated issue. --- Version 2 description: The patch to iproute2 has not changed, so I'm not including it this

Not many changes this time, just integrated a bug fix and all the coding style feedback from Eric Dumazet and Patrick McHardy. I'll keep the patch for network namespaces on the tx path out of this series for now, because the discussion is still ongoing and it addresses an unrelated issue. --- Version 2 description: The patch to iproute2 has not changed, so I'm not including it this