search for: hard_start_xmit

...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 patch also makes an oops go away when locally generated packets are sent through something like br0.1000. This is what the patch does: - add vlan_dev_hard_start_xmit_p, because br_netfilter.c needs to know the address of vlan_dev_hard_start_xmit(). When the local machine sends a packet through br0.1000, we need to allow filtering in LOCAL_OUT/FILTER on the bridge out port, so we need to be able to postpone the iptables filtering. - add nf_bridge->netoutdev f...

...et limits to stall, socket close to hang, etc.). DaveM points out that there are advantages to doing it generally (it's more likely to be on same CPU than after xmit), and I couldn't find any new starvation issues in simple benchmarking here. This patch adds skb_orphan to the start of dev_hard_start_xmit(): it can be premature in the NETDEV_TX_BUSY case, but that's uncommon. I removed the drivers' skb_orphan(), though it's harmless. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> Cc: Divy Le Ray <divy at chelsio.com> Cc: Roland Dreier <rolandd at cisco.com> C...

...et limits to stall, socket close to hang, etc.). DaveM points out that there are advantages to doing it generally (it's more likely to be on same CPU than after xmit), and I couldn't find any new starvation issues in simple benchmarking here. This patch adds skb_orphan to the start of dev_hard_start_xmit(): it can be premature in the NETDEV_TX_BUSY case, but that's uncommon. I removed the drivers' skb_orphan(), though it's harmless. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> Cc: Divy Le Ray <divy at chelsio.com> Cc: Roland Dreier <rolandd at cisco.com> C...

...not so familiar with the deep art of network internals more with the basics one. Therefore i have a problem to interpret this error message: Dead loop on virtual device br0, fix it urgently! In the corresponding kernel code i found this quote: /* It may be transient configuration error, when hard_start_xmit() recurses. We detect it by checking xmit owner and drop the packet when deadloop is detected. */ but i still have no idea what could be wrong. My setup is an bridge (two interfaces) and local interface. The bridge connects the dmz with the internet. How can i reproduce this error messag...

...hen I looked into IP header I came accross ToS field, also while going more into detail about QoS I found that the QoS based on ToS is serviced thru DiffServ which in turn gives more priority to packets with higher value is ToS field, but I am not able to understand when we finally call dev->hard_start_xmit routine of underlying device type driver, how these packets are given high priority or low priority in the device queue. Please advice me here, Thanks -krishan _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listin...

...xxp/base.c:777: error: ?struct net_device? has no member named ?open? /usr/src/dahdi-linux-2.2.0.2/drivers/dahdi/wctc4xxp/base.c:778: error: ?struct net_device? has no member named ?stop? /usr/src/dahdi-linux-2.2.0.2/drivers/dahdi/wctc4xxp/base.c:779: error: ?struct net_device? has no member named ?hard_start_xmit? /usr/src/dahdi-linux-2.2.0.2/drivers/dahdi/wctc4xxp/base.c:780: error: ?struct net_device? has no member named ?get_stats? /usr/src/dahdi-linux-2.2.0.2/drivers/dahdi/wctc4xxp/base.c:781: error: ?struct net_device? has no member named ?do_ioctl? /usr/src/dahdi-linux-2.2.0.2/drivers/dahdi/wctc4xxp/b...

Hi, I have 2 servers which are connected to a gateway machine. The gateway and one server are running Linux 2.6.16.2, while the third machine is running 2.6.16.5. The two ethernet ports on the gateway which are connected to the servers are combined into a single ethernet bridge device. Ever since 2.6.16, I have noticed that I can no longer cross-mount the two servers' /home directories via

...|| new_mtu > MAX_MTU) + return -EINVAL; + dev->mtu = new_mtu; + return 0; +} + static int virtnet_probe(struct virtio_device *vdev) { int err; @@ -628,6 +639,7 @@ static int virtnet_probe(struct virtio_device *vdev) dev->open = virtnet_open; dev->stop = virtnet_close; dev->hard_start_xmit = start_xmit; + dev->change_mtu = virtnet_change_mtu; dev->features = NETIF_F_HIGHDMA; #ifdef CONFIG_NET_POLL_CONTROLLER dev->poll_controller = virtnet_netpoll; -- 1.6.0.3

...virtnet_info *vi = netdev_priv(dev); + + napi_schedule(&vi->napi); +} +#endif + static int virtnet_open(struct net_device *dev) { struct virtnet_info *vi = netdev_priv(dev); @@ -336,6 +345,9 @@ static int virtnet_probe(struct virtio_device *vdev) dev->stop = virtnet_close; dev->hard_start_xmit = start_xmit; dev->features = NETIF_F_HIGHDMA; +#ifdef CONFIG_NET_POLL_CONTROLLER + dev->poll_controller = virtnet_netpoll; +#endif SET_NETDEV_DEV(dev, &vdev->dev); /* Do we support "hardware" checksums? */ -- 1.5.2.5 -- Amit Shah http://www.amitshah.net/

...rmat, some or all of this message may not be legible. ------_=3D_NextPart_001_01C48167.7E2F3D60 =1D=E9eI am trying to understand how the bridge code deals with the Ethernet FCS. I have written a WLAN driver, and have tied it to eth0 via the bridge utilities. What confuses me is that when my hard_start_xmit routine is called, when it is receiving data from eth0, it comes complete with the FCS. For a typical max length TCP packet, this puts the total frame length at 1504, which exceeds the 1500 Ethernet MTU. So if my an unknowing driver takes the full payload and sends it across the wireless...

...h> #include "br_private.h" @@ -44,7 +45,7 @@ struct net_bridge_port *p; struct net_bridge_port **pptr; - if ((p = dev->br_port) == NULL) + if ((p = dev->br_port) == NULL || p->br != br) return -EINVAL; br_stp_disable_port(p); @@ -231,6 +232,9 @@ if (dev->hard_start_xmit == br_dev_xmit) return -ELOOP; + + if (!is_valid_ether_addr(dev->dev_addr)) + return -EADDRNOTAVAIL; dev_hold(dev); write_lock_bh(&br->lock);

...net/virtio_net.c @@ -329,11 +329,10 @@ static int virtnet_probe(struct virtio_d dev = alloc_etherdev(sizeof(struct virtnet_info)); if (!dev) return -ENOMEM; /* Set up network device as normal. */ - ether_setup(dev); dev->open = virtnet_open; dev->stop = virtnet_close; dev->hard_start_xmit = start_xmit; dev->features = NETIF_F_HIGHDMA; SET_NETDEV_DEV(dev, &vdev->dev);

...have found a problem in the virtio network driver. virtio_net reclaims sent skbs on xmit. That means that there is always one skb outstanding and the netdev packet statistic is always one packet to low. Documentation/networking/drivers.txt says 3) Do not forget that once you return 0 from your hard_start_xmit method, it is your driver's responsibility to free up the SKB and in some finite amount of time. For example, this means that it is not allowed for your TX mitigation scheme to let TX packets "hang out" in the TX ring unreclaimed forever if no new TX packets are sent....

...have found a problem in the virtio network driver. virtio_net reclaims sent skbs on xmit. That means that there is always one skb outstanding and the netdev packet statistic is always one packet to low. Documentation/networking/drivers.txt says 3) Do not forget that once you return 0 from your hard_start_xmit method, it is your driver's responsibility to free up the SKB and in some finite amount of time. For example, this means that it is not allowed for your TX mitigation scheme to let TX packets "hang out" in the TX ring unreclaimed forever if no new TX packets are sent....

...net/virtio_net.c @@ -329,11 +329,10 @@ static int virtnet_probe(struct virtio_d dev = alloc_etherdev(sizeof(struct virtnet_info)); if (!dev) return -ENOMEM; /* Set up network device as normal. */ - ether_setup(dev); dev->open = virtnet_open; dev->stop = virtnet_close; dev->hard_start_xmit = start_xmit; dev->features = NETIF_F_HIGHDMA; SET_NETDEV_DEV(dev, &vdev->dev);

...virtnet_info *vi = netdev_priv(dev); + + napi_schedule(&vi->napi); +} +#endif + static int virtnet_open(struct net_device *dev) { struct virtnet_info *vi = netdev_priv(dev); @@ -336,6 +345,9 @@ static int virtnet_probe(struct virtio_device *vdev) dev->stop = virtnet_close; dev->hard_start_xmit = start_xmit; dev->features = NETIF_F_HIGHDMA; +#ifdef CONFIG_NET_POLL_CONTROLLER + dev->poll_controller = virtnet_netpoll; +#endif SET_NETDEV_DEV(dev, &vdev->dev); /* Do we support "hardware" checksums? */ -- 1.5.2.5 -- Amit Shah http://www.amitshah.net/

...|| new_mtu > MAX_MTU) + return -EINVAL; + dev->mtu = new_mtu; + return 0; +} + static int virtnet_probe(struct virtio_device *vdev) { int err; @@ -628,6 +639,7 @@ static int virtnet_probe(struct virtio_device *vdev) dev->open = virtnet_open; dev->stop = virtnet_close; dev->hard_start_xmit = start_xmit; + dev->change_mtu = virtnet_change_mtu; dev->features = NETIF_F_HIGHDMA; #ifdef CONFIG_NET_POLL_CONTROLLER dev->poll_controller = virtnet_netpoll; -- 1.6.0.3

...r's handlers lock > between lapbether & bridge modules. > > I've made a modification for hdlc_cisco.c, 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 &g...

...H_HLEN); skb->protocol = eth_type_trans(skb,&brg->dev); netif_rx(skb); return; } void Bridge_dev_setup(struct net_device *dev) { unsigned char dd[6] = {0x12,0x12,0x12,0x12,0x12,0x12}; memcpy(dev->dev_addr,dd,ETH_ALEN); dev->do_ioctl = NULL; dev->get_stats = NULL; dev->hard_start_xmit = NULL; dev->open = NULL; dev->set_multicast_list = NULL; dev->stop = NULL; dev->accept_fastpath = NULL; dev->tx_queue_len = 0; dev->set_mac_address = NULL; } ????????wrath8x@163.com ??????????2005-04-24

Herbert tells me that returning NETDEV_TX_BUSY from hard_start_xmit is seen as a poor thing to do; we should cache the packet and stop the queue. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> --- drivers/net/virtio_net.c | 57 +++++++++++++++++++++++++++++++---------------- 1 file changed, 38 insertions(+), 19 deletions(-) diff -r a936d320f6d5...