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/
Home Products Support Community News


[Xen-devel] Re: [PATCH RESEND] net: convert xen-netfront to hw_features

On Sat, 2011-04-02 at 04:54 +0100, David Miller wrote:
> From: Michał Mirosław <mirq-linux@xxxxxxxxxxxx>
> Date: Thu, 31 Mar 2011 13:01:35 +0200 (CEST)
> > Not tested in any way. The original code for offload setting seems broken
> > as it resets the features on every netback reconnect.
> > 
> > This will set GSO_ROBUST at device creation time (earlier than connect 
> > time).
> > 
> > RX checksum offload is forced on - so advertise as it is.
> > 
> > Signed-off-by: Michał Mirosław <mirq-linux@xxxxxxxxxxxx>
> Applied.

Thanks, but unfortunately the patch results in the features all being
disabled by default, since they are not set in the initial dev->features
and the initial dev->wanted_features is based on features & hw_features.
The ndo_fix_features hook only clears features and doesn't add new
features (nor should it AFAICT).

Features cannot be negotiated with the backend until xennet_connect().
The carrier is not enabled until the end of that function, therefore I
think it is safe to start with a full set of features in dev->features
and rely on the call to netdev_update_features() in xennet_connect() to
clear those which turn out to be unavailable.

The following works for me, I guess the alternative is for
xennet_connect() to expand dev->features based on what it detects? Or is
there a mechanism for a driver to inform the core that a new hardware
feature has become available (I doubt that really happens on physical
h/w so I guess not).



>From 0b56469abe56efae415b4603ef508ce9aec0e4c1 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@xxxxxxxxxx>
Date: Mon, 4 Apr 2011 10:58:50 +0100
Subject: [PATCH] xen: netfront: assume all hw features are available until 
backend connection setup

We need to assume that all features will be available when registering the
netdev otherwise they are ommitted from the initial set of
dev->wanted_features. When we connect to the backed we reduce the set as
necessary due to the call to netdev_update_features() in xennet_connect().

Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
Cc: mirq-linux@xxxxxxxxxxxx
Cc: netdev@xxxxxxxxxxxxxxx <netdev@xxxxxxxxxxxxxxx>
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Cc: konrad.wilk@xxxxxxxxxx
Cc: Eric Dumazet <eric.dumazet@xxxxxxxxx>
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
 drivers/net/xen-netfront.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 0cfe4cc..db9a763 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1251,6 +1251,14 @@ static struct net_device * __devinit 
xennet_create_dev(struct xenbus_device *dev
        netdev->hw_features     = NETIF_F_IP_CSUM | NETIF_F_SG | NETIF_F_TSO;
+       /*
+         * Assume that all hw features are available for now. This set
+         * will be adjusted by the call to netdev_update_features() in
+         * xennet_connect() which is the earliest point where we can
+         * negotiate with the backend regarding supported features.
+         */
+       netdev->features |= netdev->hw_features;
        SET_ETHTOOL_OPS(netdev, &xennet_ethtool_ops);
        SET_NETDEV_DEV(netdev, &dev->dev);

Xen-devel mailing list