WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Michał Mirosław <mirqus@xxxxxxxxx>
Subject: [Xen-devel] Re: [GIT/PATCH v4] xen network backend driver
From: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Date: Mon, 14 Mar 2011 13:43:44 +0000
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, "netdev@xxxxxxxxxxxxxxx" <netdev@xxxxxxxxxxxxxxx>, Michał Mirosław <mirq-linux@xxxxxxxxxxxx>, Francois Romieu <romieu@xxxxxxxxxxxxx>, Ben Hutchings <bhutchings@xxxxxxxxxxxxxx>
Delivery-date: Mon, 14 Mar 2011 06:45:15 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AANLkTinHyFLRkeb60x4Q6uUw6p43XBjk5rpqCMo49WKF@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <1299776554.17339.824.camel@xxxxxxxxxxxxxxxxxxxxxx> <AANLkTinHyFLRkeb60x4Q6uUw6p43XBjk5rpqCMo49WKF@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Thu, 2011-03-10 at 17:33 +0000, Michał Mirosław wrote:
> 2011/3/10 Ian Campbell <Ian.Campbell@xxxxxxxxxx>:
> > The following patch is the fourth 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.
> [...]
> > --- /dev/null
> > +++ b/drivers/net/xen-netback/common.h
> > @@ -0,0 +1,162 @@
> [...]
> > +struct xenvif {
> [...]
> > +       /* Flags that must not be set in dev->features */
> > +       int features_disabled;
> > +
> > +       /* Frontend feature information. */
> > +       u8 can_sg:1;
> > +       u8 gso:1;
> > +       u8 gso_prefix:1;
> > +       u8 csum:1;
> [...]
> > --- /dev/null
> > +++ b/drivers/net/xen-netback/interface.c
> > @@ -0,0 +1,424 @@
> [...]
> > +static int xenvif_change_mtu(struct net_device *dev, int mtu)
> > +{
> > +       struct xenvif *vif = netdev_priv(dev);
> > +       int max = vif->can_sg ? 65535 - VLAN_ETH_HLEN : ETH_DATA_LEN;
> > +
> > +       if (mtu > max)
> > +               return -EINVAL;
> > +       dev->mtu = mtu;
> > +       return 0;
> > +}
> > +
> > +static void xenvif_set_features(struct xenvif *vif)
> > +{
> > +       struct net_device *dev = vif->dev;
> > +       int features = dev->features;
> > +
> > +       if (vif->can_sg)
> > +               features |= NETIF_F_SG;
> > +       if (vif->gso || vif->gso_prefix)
> > +               features |= NETIF_F_TSO;
> > +       if (vif->csum)
> > +               features |= NETIF_F_IP_CSUM;
> > +
> > +       features &= ~(vif->features_disabled);
> > +
> > +       if (!(features & NETIF_F_SG) && dev->mtu > ETH_DATA_LEN)
> > +               dev->mtu = ETH_DATA_LEN;
> > +
> > +       dev->features = features;
> > +}
> > +
> > +static int xenvif_set_tx_csum(struct net_device *dev, u32 data)
> > +{
> > +       struct xenvif *vif = netdev_priv(dev);
> > +       if (data) {
> > +               if (!vif->csum)
> > +                       return -EOPNOTSUPP;
> > +               vif->features_disabled &= ~NETIF_F_IP_CSUM;
> > +       } else {
> > +               vif->features_disabled |= NETIF_F_IP_CSUM;
> > +       }
> > +
> > +       xenvif_set_features(vif);
> > +       return 0;
> > +}
> > +
> > +static int xenvif_set_sg(struct net_device *dev, u32 data)
> > +{
> > +       struct xenvif *vif = netdev_priv(dev);
> > +       if (data) {
> > +               if (!vif->can_sg)
> > +                       return -EOPNOTSUPP;
> > +               vif->features_disabled &= ~NETIF_F_SG;
> > +       } else {
> > +               vif->features_disabled |= NETIF_F_SG;
> > +       }
> > +
> > +       xenvif_set_features(vif);
> > +       return 0;
> > +}
> > +
> > +static int xenvif_set_tso(struct net_device *dev, u32 data)
> > +{
> > +       struct xenvif *vif = netdev_priv(dev);
> > +       if (data) {
> > +               if (!vif->gso && !vif->gso_prefix)
> > +                       return -EOPNOTSUPP;
> > +               vif->features_disabled &= ~NETIF_F_TSO;
> > +       } else {
> > +               vif->features_disabled |= NETIF_F_TSO;
> > +       }
> > +
> > +       xenvif_set_features(vif);
> > +       return 0;
> > +}
> [...]
> 
> You could make this simpler by using netdev->hw_features and
> ndo_fix_features/ndo_set_features calls recently introduced in
> net-next.

Thanks, this does look like it could simplify things. Doesn't look like
its use is widespread (even net-next) yet though?

I'll add it to my TODO list for the future.

>  I'll reply with a proof-of-concept patch for xen-netfront.
> 
> Best Regards,
> Michał Mirosław



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