On Tue, 2015-12-08 at 19:43 +0000, Liang, Kan wrote:
>
> >
> > On Tue, 2015-12-08 at 10:02 -0800, Shannon Nelson wrote:
> > > On Mon, Dec 7, 2015 at 8:42 PM, <kan.li...@intel.com> wrote:
> > > > From: Kan Liang <kan.li...@intel.com>
> > > >
> > > > Intrdouce "queue" option for coalesce getting and setting.
> > [...]
> > > > --- a/net/core/ethtool.c
> > > > +++ b/net/core/ethtool.c
> > > > @@ -1123,10 +1123,16 @@ static noinline_for_stack int
> > > > ethtool_get_coalesce(struct net_device *dev,
> > > > void __user
> > > > *useraddr)
> > > > {
> > > > struct ethtool_coalesce coalesce = { .cmd =
> > > > ETHTOOL_GCOALESCE };
> > > > + struct ethtool_coalesce tmp = { .queue = -1 };
> > > >
> > > > if (!dev->ethtool_ops->get_coalesce)
> > > > return -EOPNOTSUPP;
> > > >
> > > > + if (copy_from_user(&tmp, useraddr, sizeof(coalesce)))
> > > > + return -EFAULT;
> > > > +
> > > > + coalesce.queue = tmp.queue;
> > > > +
> > >
> > > Is this going to do what you expect when you have an older ethtool
> > > program? It seems to me that the older ethtool program will have the
> > > original coalesce struct without the new queue field, so when you do
> > [...]
> >
> > Indeed, it's not safe to extend UAPI structures like this.
>
> Any suggestions for that?
> If we cannot extend the existing UAPI structures. I guess we have to add
> a new Ioctl like ETHTOOL_GCOALESCE_V2 for the new structure?Something like that. While you're at it, add a flags field which will indicate which of the others are supported. Also, there was some talk of adding settings for RX DMA coalescing. Ben. -- Ben Hutchings Life would be so much easier if we could look at the source code.
signature.asc
Description: This is a digitally signed message part
