Ok, sending new patches...
On Wed, Apr 3, 2013 at 2:25 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Wed, Apr 03, 2013 at 11:50:19AM +1030, Rusty Russell wrote: > > Dmitry Fleytman <dmi...@daynix.com> writes: > > > From: Dmitry Fleytman <dfley...@redhat.com> > > > > > > Virtio-net driver currently negotiates network offloads > > > on startup via features mechanism and have no ability to > > > change offloads state later. > > > This patch introduced a new control command that allows > > > to configure device network offloads state dynamically. > > > The patch also introduces a new feature flag > > > VIRTIO_NET_F_CTRL_GUEST_OFFLOADS. > > > > > > Signed-off-by: Dmitry Fleytman <dfley...@redhat.com> > > > > (BTW, I like to be CC'd on these things directly, so I don't miss them) > > > > The idea is fine. > > > > But I dislike the duplication of constants: let's just use the feature > > bits directly: > > > > #define VIRTIO_NET_F_GUEST_CSUM 1 /* Guest handles pkts w/ > partial csum */ > > #define VIRTIO_NET_F_GUEST_TSO4 7 /* Guest can handle TSOv4 > in. */ > > #define VIRTIO_NET_F_GUEST_TSO6 8 /* Guest can handle TSOv6 > in. */ > > #define VIRTIO_NET_F_GUEST_ECN 9 /* Guest can handle TSO[6] > w/ ECN in. */ > > #define VIRTIO_NET_F_GUEST_UFO 10 /* Guest can handle UFO > in. */ > > > > You want this, because you have to test against them anyway before > > trying to re-enable them. > > > > And secondly, it'll be much clearer if you don't say "change" but > > "disable and re-enable", which is what's actually allowed. > > > > Thanks, > > Rusty. > > Okay and let's make command it bigger, say 64 bit then, > in case we add lots of feature bits in the future? > > >
