search for: tcpv4

...0 frontend = "/local/domain/5/device/vif/0" frontend-id = "5" online = "1" state = "4" script = "/etc/xen/scripts/vif-bridge" mac = "00:16:3e:56:df:85" bridge = "eth1" handle = "0" feature-sg = "1" feature-gso-tcpv4 = "1" feature-rx-copy = "1" feature-rx-flip = "0" feature-smart-poll = "1" hotplug-status = "connected" *xm create* /usr/bin/xenstore-ls /local/domain/0/backend/vif/6/0 bridge = "eth1" domain = "vl261" handle = "0" uu...

...0 frontend = "/local/domain/5/device/vif/0" frontend-id = "5" online = "1" state = "4" script = "/etc/xen/scripts/vif-bridge" mac = "00:16:3e:56:df:85" bridge = "eth1" handle = "0" feature-sg = "1" feature-gso-tcpv4 = "1" feature-rx-copy = "1" feature-rx-flip = "0" feature-smart-poll = "1" hotplug-status = "connected" *xm create* /usr/bin/xenstore-ls /local/domain/0/backend/vif/6/0 bridge = "eth1" domain = "domU" handle = "0" uui...

...offload"; goto abort_transaction; } -#endif err = xenbus_printf(xbt, dev->nodename, "feature-sg", "%d", 1); if (err) { @@ -426,13 +431,12 @@ again: goto abort_transaction; } -#ifdef HAVE_TSO - err = xenbus_printf(xbt, dev->nodename, "feature-gso-tcpv4", "%d", 1); + err = xenbus_printf(xbt, dev->nodename, "feature-gso-tcpv4", "%d", + HAVE_TSO); if (err) { message = "writing feature-gso-tcpv4"; goto abort_transaction; } -#endif err = xenbus_transaction_end(xbt, 0); if (err) { @@...

...; -} - -static int xennet_set_tso(struct net_device *dev, u32 data) -{ - if (data) { - struct netfront_info *np = netdev_priv(dev); - int val; + features &= ~NETIF_F_SG; + } + if (features & NETIF_F_TSO) { if (xenbus_scanf(XBT_NIL, np->xbdev->otherend, "feature-gso-tcpv4", "%d", &val) < 0) val = 0; + if (!val) - return -ENOSYS; + features &= ~NETIF_F_TSO; } - return ethtool_op_set_tso(dev, data); + return features; } -static void xennet_set_features(struct net_device *dev) +static int xennet_set_features(struct net_device...

...; -} - -static int xennet_set_tso(struct net_device *dev, u32 data) -{ - if (data) { - struct netfront_info *np = netdev_priv(dev); - int val; + features &= ~NETIF_F_SG; + } + if (features & NETIF_F_TSO) { if (xenbus_scanf(XBT_NIL, np->xbdev->otherend, "feature-gso-tcpv4", "%d", &val) < 0) val = 0; + if (!val) - return -ENOSYS; + features &= ~NETIF_F_TSO; } - return ethtool_op_set_tso(dev, data); + return features; } -static void xennet_set_features(struct net_device *dev) +static int xennet_set_features(struct net_device...

...; -} - -static int xennet_set_tso(struct net_device *dev, u32 data) -{ - if (data) { - struct netfront_info *np = netdev_priv(dev); - int val; + features &= ~NETIF_F_SG; + } + if (features & NETIF_F_TSO) { if (xenbus_scanf(XBT_NIL, np->xbdev->otherend, "feature-gso-tcpv4", "%d", &val) < 0) val = 0; + if (!val) - return -ENOSYS; + features &= ~NETIF_F_TSO; } - return ethtool_op_set_tso(dev, data); + return features; } -static void xennet_set_features(struct net_device *dev) +static int xennet_set_features(struct net_device...

...drivers/net/xen-netback/interface.c @@ -214,8 +214,10 @@ static netdev_features_t xenvif_fix_features(struct net_device *dev, if (!vif->can_sg) features &= ~NETIF_F_SG; - if (!vif->gso && !vif->gso_prefix) + if (~(vif->gso_mask | vif->gso_prefix_mask) & GSO_BIT(TCPV4)) features &= ~NETIF_F_TSO; + if (~(vif->gso_mask | vif->gso_prefix_mask) & GSO_BIT(TCPV6)) + features &= ~NETIF_F_TSO6; if (!vif->ip_csum) features &= ~NETIF_F_IP_CSUM; if (!vif->ipv6_csum) @@ -320,7 +322,7 @@ struct xenvif *xenvif_alloc(struct device *parent...

...e packet header or prepare the skb if it not an Ethernet frame. > > It is interesting to know when we get < 60B frame. If I recall, a UDPv4 frame can easily do it since Ethernet is 14B, IP header is 20, and UDP is only 8 so that only comes to 42B if I recall correctly. Similarly I think a TCPv4 Frame can be as small as 54B if you disable all the option headers. A quick and dirty test would be to run something like a netperf UDP_RR test. I know in the case of the network stack we see the transmits that go out are less than 60B until they are padded on xmit, usually by the device. My conce...

...ref( @@ -804,14 +805,14 @@ static int xennet_set_skb_gso(struct sk_buff *skb, { if (!gso->u.gso.size) { if (net_ratelimit()) - printk(KERN_WARNING "GSO size must not be zero.\n"); + pr_warn("GSO size must not be zero\n"); return -EINVAL; } /* Currently only TCPv4 S.O. is supported. */ if (gso->u.gso.type != XEN_NETIF_GSO_TYPE_TCPV4) { if (net_ratelimit()) - printk(KERN_WARNING "Bad GSO type %d.\n", gso->u.gso.type); + pr_warn("Bad GSO type %d\n", gso->u.gso.type); return -EINVAL; } @@ -910,9 +911,8 @@ static int...

...ref( @@ -804,14 +805,14 @@ static int xennet_set_skb_gso(struct sk_buff *skb, { if (!gso->u.gso.size) { if (net_ratelimit()) - printk(KERN_WARNING "GSO size must not be zero.\n"); + pr_warn("GSO size must not be zero\n"); return -EINVAL; } /* Currently only TCPv4 S.O. is supported. */ if (gso->u.gso.type != XEN_NETIF_GSO_TYPE_TCPV4) { if (net_ratelimit()) - printk(KERN_WARNING "Bad GSO type %d.\n", gso->u.gso.type); + pr_warn("Bad GSO type %d\n", gso->u.gso.type); return -EINVAL; } @@ -910,9 +911,8 @@ static int...

...ref( @@ -804,14 +805,14 @@ static int xennet_set_skb_gso(struct sk_buff *skb, { if (!gso->u.gso.size) { if (net_ratelimit()) - printk(KERN_WARNING "GSO size must not be zero.\n"); + pr_warn("GSO size must not be zero\n"); return -EINVAL; } /* Currently only TCPv4 S.O. is supported. */ if (gso->u.gso.type != XEN_NETIF_GSO_TYPE_TCPV4) { if (net_ratelimit()) - printk(KERN_WARNING "Bad GSO type %d.\n", gso->u.gso.type); + pr_warn("Bad GSO type %d\n", gso->u.gso.type); return -EINVAL; } @@ -910,9 +911,8 @@ static int...

I guess I have stumbled upon a bug in gplpv drivers. If you try to re-enable an nic adapter after disabling it, it just hides out of blue. And you have to reboot. Latest version of gplpv drivers and Windows 2008 R2 here. Anyone else noticed the same issue? I wonder if this is related to hot-plugging something like

...The only solution for these is to use our own stack (likely full TCP/IP like lwIP) and connect to the Net GUID (EFI_SIMPLE_NETWORK_PROTOCOL).? Does the handle for Pxebc contain a Net?? >>> It does contain a Net but there are 2 issues with SNP: 1) The interface is different than UDPv4/TCPv4 protocols; this imply lot of code. 2) SNP has its non-blocking transmit issues ; see "Flaws in the design" at https://wiki.linaro.org/LEG/Engineering/Kernel/UEFI/UEFI_Network_Driver >>> I found out that my EFI shell on VMware VMs can also handle output redirection like: guid...

...= "/etc/xen/scripts/vif-route-atw" vifname = "x" mac = "00:16:3e:00:01:0d" ip = "x" bridge = "xenbr0" handle = "0" type = "vif_ioemu" feature-sg = "1" feature-gso-tcpv4 = "1" feature-rx-copy = "1" feature-rx-flip = "0" hotplug-status = "connected"

Does the data for a large send offload have to occupy more than one page? In tuning the windows drivers, if I set the minimum mss multiple before considering offload (a windows variable) to 2, then I seem to get hangs. If I set it to 4 then everything appears to be okay. If the mss is 1460 (normal for Ethernet), then 2 * 1460 = 2920, which will often fit into one page, in which case the ring

...hese is to use our own stack (likely full > TCP/IP like lwIP) and connect to the Net GUID (EFI_SIMPLE_NETWORK_PROTOCOL). > Does the handle for Pxebc contain a Net? >>>> > > It does contain a Net but there are 2 issues with SNP: > 1) The interface is different than UDPv4/TCPv4 protocols; this imply lot of code. Not as much as you may think. We already have lwIP implemented into lpxelinux.0. It's more a matter of using more glue. > 2) SNP has its non-blocking transmit issues ; see "Flaws in the design" at > https://wiki.linaro.org/LEG/Engineering/K...

I''ve just uploaded 0.9.11-pre12 of the GPL PV drivers for Windows. Since -pre10 (and -pre11) I''ve fixed a heap of crashes that were plaguing xennet under load, and also rewritten the interrupt/event distribution logic to improve performance. Under windows 2003 I can now get network speeds of 1-2Gbit/second TX and 600Gbit/second RX, which is considerably better than I was

I''ve just uploaded 0.9.11-pre12 of the GPL PV drivers for Windows. Since -pre10 (and -pre11) I''ve fixed a heap of crashes that were plaguing xennet under load, and also rewritten the interrupt/event distribution logic to improve performance. Under windows 2003 I can now get network speeds of 1-2Gbit/second TX and 600Gbit/second RX, which is considerably better than I was

>>> > It does contain a Net but there are 2 issues with SNP: > 1) The interface is different than UDPv4/TCPv4 protocols; this imply lot of code. Not as much as you may think.? We already have lwIP implemented into lpxelinux.0.? It's more a matter of using more glue. > 2) SNP has its non-blocking transmit issues ; see "Flaws in the design" at > https://wiki.linaro.org/LEG/Enginee...

...envif *vif, struct xen_netif_extra_info *gso) { if (!gso->u.gso.size) { - netdev_dbg(vif->dev, "GSO size must not be zero.\n"); + netdev_err(vif->dev, "GSO size must not be zero.\n"); + netbk_fatal_tx_err(vif); return -EINVAL; } /* Currently only TCPv4 S.O. is supported. */ if (gso->u.gso.type != XEN_NETIF_GSO_TYPE_TCPV4) { - netdev_dbg(vif->dev, "Bad GSO type %d.\n", gso->u.gso.type); + netdev_err(vif->dev, "Bad GSO type %d.\n", gso->u.gso.type); + netbk_fatal_tx_err(vif); return -EINVAL; } @@ -1264...