similar to: [Bridge] Re: [PATCH] TSO fix in br_dev_queue_push_xmit

From: xu xin <xu.xin16 at zte.com.cn> This creates six drop reasons as follows, which will help users know the specific reason why bridge drops the packets when forwarding. 1) SKB_DROP_REASON_BRIDGE_FWD_NO_BACKUP_PORT: failed to get a backup port link when the destination port is down. 2) SKB_DROP_REASON_BRIDGE_FWD_SAME_PORT: destination port is the same with originating port when

Looks like the GSO is involved? I got this while running Dom0 only (no guests), with a BOINC/Rosetta@home application running on all 4 cores. changeset: 10649:8e55c5c11475 Build: x86_32p (pae). ------------[ cut here ]------------ kernel BUG at net/core/dev.c:1133! invalid opcode: 0000 [#1] SMP CPU: 0 EIP: 0061:[<c04dceb0>] Not tainted VLI EFLAGS: 00210297 (2.6.16.13-xen

Hi Stephen, there was a bug in bridging bonds. multicast packets needed for 802.3ad netif_carrier_ok() were dropped. attached patch works for me. Cheers, Vlad. -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_br_multicast.patch Type: text/x-patch Size: 1344 bytes Desc: not available Url :

On Thu, May 18, 2023 at 07:08:47PM +0300, Nikolay Aleksandrov wrote: > On 18/05/2023 14:33, Ido Schimmel wrote: > > diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c > > index fc17b9fd93e6..d8ab5890cbe6 100644 > > --- a/net/bridge/br_input.c > > +++ b/net/bridge/br_input.c > > @@ -334,6 +334,7 @@ static rx_handler_result_t br_handle_frame(struct sk_buff

Hi Keir: [LINUX] netfront: Cleanup and fix TSO/GSO/CHECKSUM conditionals This patch tries to minimise the amount of code that is conditionally compiled. This is desirable (and the Linux way) as it helps to prevent people breaking code unwittingly since conditionals may hide compile problems. It also adds a missing conditional around the TSO ethtool operations. This also helps the building of

Hi, I have just configured a Linux box with kernel 2.6.16.7 and configured two ethernet interfaces (with MTU 1500) in bridge mode. CONFIG_BRIDGE_NETFILTER is enabled. The problem is that ping -s 1500 192.168.0.2 doesn't work from 192.168.0.1 if the systems are separated by the bridge. Normal ping with smaller packet size works ok. What is wrong? Best Regards Fulvio Ricciardi

Hi all, The patch below does four trivial changes and one big change Trivial changes, these are all in br_netfilter.c: - check ar_pln==4 when giving bridged ARP packets to arptables - delete unnecessary if in br_nf_local_in - add more logging for the "Argh" message - add some brag-comments in the file head comment Big change: let {ip,arp}tables see VLAN tagged {I,AR}P packets. This

This patch adds basic Virtual Ethernet Port Aggregator (VEPA) capabilities to the Linux kernel Ethernet bridging code. A Virtual Ethernet Port Aggregator (VEPA) is a capability within a physical end station that collaborates with an adjacent, external bridge to provide distributed bridging support between multiple virtual end stations and external networks. The VEPA collaborates by forwarding all

This patch adds basic Virtual Ethernet Port Aggregator (VEPA) capabilities to the Linux kernel Ethernet bridging code. A Virtual Ethernet Port Aggregator (VEPA) is a capability within a physical end station that collaborates with an adjacent, external bridge to provide distributed bridging support between multiple virtual end stations and external networks. The VEPA collaborates by forwarding all

This patch adds basic Virtual Ethernet Port Aggregator (VEPA) capabilities to the Linux kernel Ethernet bridging code. A Virtual Ethernet Port Aggregator (VEPA) is a capability within a physical end station that collaborates with an adjacent, external bridge to provide distributed bridging support between multiple virtual end stations and external networks. The VEPA collaborates by forwarding all

This patch adds a 'hairpin' (also called 'reflective relay') mode port configuration to the Linux Ethernet bridge kernel module. A bridge supporting hairpin forwarding mode can send frames back out through the port the frame was received on. Hairpin mode is required to support basic VEPA (Virtual Ethernet Port Aggregator) capabilities. You can find additional information on VEPA

This patch adds a 'hairpin' (also called 'reflective relay') mode port configuration to the Linux Ethernet bridge kernel module. A bridge supporting hairpin forwarding mode can send frames back out through the port the frame was received on. Hairpin mode is required to support basic VEPA (Virtual Ethernet Port Aggregator) capabilities. You can find additional information on VEPA

This patch adds a 'hairpin' (also called 'reflective relay') mode port configuration to the Linux Ethernet bridge kernel module. A bridge supporting hairpin forwarding mode can send frames back out through the port the frame was received on. Hairpin mode is required to support basic VEPA (Virtual Ethernet Port Aggregator) capabilities. You can find additional information on VEPA

The following series adds 2 new flags to bridge. One flag allows the user to control whether mac learning is performed on the interface or not. By default mac learning is on. The other flag allows the user to control whether unicast traffic is flooded (send without an fdb) to a given unicast port. Default is on. Changes since v4: - Implemented Stephen's suggestions. Changes since v2: -

Hi, The attached patches enables the bridge to filter and forward packets according to their IEEE 802.1q headers. The goals behind this change include : - Enable running STP on 802.1q tagged networks. STP packets must be untagged. It isn't obvious how else to enable STP with the current bridge and vlan code. - Add native support for an untagged vlan. Currently an untagged vlan can

same patch as 2.4, just the offsets are changed. diff -Nru a/net/bridge/br_forward.c b/net/bridge/br_forward.c --- a/net/bridge/br_forward.c Mon Sep 8 09:31:19 2003 +++ b/net/bridge/br_forward.c Mon Sep 8 09:31:19 2003 @@ -69,6 +69,7 @@ indev = skb->dev; skb->dev = to->dev; + skb->ip_summed = CHECKSUM_NONE; NF_HOOK(PF_BRIDGE, NF_BR_FORWARD, skb, indev, skb->dev,

The hardware checksumming flags need to be cleared when forwarding packets. Bridging just needs to forward what ever checksum is in the existing skbuff, it doesn't want or need the packet to be resummed. Without this fix, forwarding between smart/dumb interfaces causes an oops. diff -Nru a/net/bridge/br_forward.c b/net/bridge/br_forward.c --- a/net/bridge/br_forward.c Mon Sep 8 09:29:44

Hi, What's the correct way to disble TSO (TCP Segmentation Offload) in RHEL5? I have tried adding those options in ifcfg-ethX configuration file: # grep ETHTOOL /etc/sysconfig/network-scripts/ifcfg-eth0 ETHTOOL_OPTS="tso off" And also with: ETHTOOL_OPTS="-K eth0 tso off" But when restating the server TSO is enabled: # ethtool -k eth0 tcp segmentation offload: on As

Seems like an oversight that we have set-tx-csum and set-sg hooked up, but not set-tso. Also leads to the strange situation that if you e.g. disable tx-csum, then tso doesn't get disabled. Signed-off-by: Mark McLoughlin <markmc at redhat.com> --- drivers/net/virtio_net.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/net/virtio_net.c

Hello, Writing to seek help in regard to some unexpected performance anomaly i am observing in using tsoutlers:tso on the mac vs on an AWS cloud server.. I am running the following code with very small dataset of about 208 records. d.dir <- '/Users/darshanpandya/xxxxxx' FNAME <- 'my_data.csv' d.input <- fread(file.path(paste0(d.dir,"/zzz/"),FNAME,fsep =