[Xen-devel] Re: [GIT/PATCH v3] xen network backend driver

[Ben Hutchings <bhutchings@xxxxxxxxxxxxxx>]

On Mon, 2011-02-28 at 17:27 +0000, Ian Campbell wrote:
> The following patch is the third iteration of the Xen network backend
> driver for upstream Linux.
> 
> This driver ("netback") is the host side counterpart to the frontend
> driver in drivers/net/xen-netfront.c. The PV protocol is also
> implemented by frontend drivers in other OSes too, such as the BSDs and
> even Windows.
> 
> Since this is the third posting I think it is time I started posting
> actual pull requests. The complete patch is still appended for ease of
> review.
[...]
> --- /dev/null
> +++ b/drivers/net/xen-netback/common.h
[...]
> +     /* Statistics */
> +     int rx_gso_checksum_fixup;

This should be defined as unsigned long (ideally it would be u64, but
that can't be updated atomically on 32-bit systems).

[...]
> --- /dev/null
> +++ b/drivers/net/xen-netback/interface.c
[...]
> +void xenvif_receive_skb(struct xenvif *vif, struct sk_buff *skb)
> +{
> +     netif_rx_ni(skb);
> +     vif->dev->last_rx = jiffies;
> +}

Don't update last_rx; it's only needed on slave devices of a bond, and
the bonding driver takes care of it now.

[...]
> +static int xenvif_change_mtu(struct net_device *dev, int mtu)
> +{
> +     struct xenvif *vif = netdev_priv(dev);
> +     int max = vif->can_sg ? 65535 - ETH_HLEN : ETH_DATA_LEN;
> +     if (mtu > max)
> +             return -EINVAL;
> +     dev->mtu = mtu;
> +     return 0;
> +}
[...]

Since any VLAN tag must be inserted inline, shouldn't the MTU limit be
65535 - VLAN_ETH_HLEN?

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel