* RE: [PATCH 2/3] bridge: offload bridge port attributes to switch asic if feature flag set
From: Arad, Ronen @ 2014-12-06 8:05 UTC (permalink / raw)
To: Scott Feldman, Netdev
Cc: Roopa Prabhu, Jirí Pírko, Jamal Hadi Salim,
Benjamin LaHaise, Thomas Graf, john fastabend,
stephen@networkplumber.org, John Linville, nhorman@tuxdriver.com,
Nicolas Dichtel, vyasevic@redhat.com, Florian Fainelli,
buytenh@wantstofly.org, Aviad Raveh, David S. Miller,
shm@cumulusnetworks.com, Andy Gospodarek
In-Reply-To: <CAE4R7bChFLfCX5z4FTWHfnpNuYKnkTtD64xg5BE0yAwA381w3g@mail.gmail.com>
> -----Original Message-----
> From: Scott Feldman [mailto:sfeldma@gmail.com]
> Sent: Friday, December 05, 2014 10:29 PM
> To: Arad, Ronen
> Cc: Roopa Prabhu; Netdev; Jirí Pírko; Jamal Hadi Salim; Benjamin LaHaise;
> Thomas Graf; john fastabend; stephen@networkplumber.org; John Linville;
> nhorman@tuxdriver.com; Nicolas Dichtel; vyasevic@redhat.com; Florian
> Fainelli; buytenh@wantstofly.org; Aviad Raveh; David S. Miller;
> shm@cumulusnetworks.com; Andy Gospodarek
> Subject: Re: [PATCH 2/3] bridge: offload bridge port attributes to switch asic
> if feature flag set
>
> On Fri, Dec 5, 2014 at 5:04 PM, Arad, Ronen <ronen.arad@intel.com> wrote:
> > I have another case of propagation which is not covered by the proposed
> patch.
> > A recent patch introduced default_pvid attribute for a bridge (so far
> supported only via sysfs and not via netlink).
> > When a port joins a bridge, it inherits a PVID from the default_pvid of the
> bridge.
> > The bridge driver propagates that to the newly created net_bridge_port.
> This is done in br_vlan.c:
> >
> > int nbp_vlan_init(struct net_bridge_port *p) {
> > int rc = 0;
> >
> > if (p->br->default_pvid) {
> > rc = nbp_vlan_add(p, p->br->default_pvid,
> > BRIDGE_VLAN_INFO_PVID |
> > BRIDGE_VLAN_INFO_UNTAGGED);
> > }
> >
> > return rc;
> > }
> >
> > When L2 switching is offloaded to the HW, this PVID setting need to be
> propagated.
>
> Agreed, it would be nice to have it propagated down, but there is a non-ideal
> work-around. If you set default_pvid=0 to turn off PVID, then the switch port
> driver can pick some internal VLAN ID just for HW purposes in matching
> untagged pkts. It's non-ideal because the switch port driver needs to reserve
> a block of VLAN IDs for internal usage or use some other matching
> mechanism to keep untagged pkts within this bridge.
This work-around let the administrator avoid using VID=1 as the default VLAN for untagged frames. However, it does not let the administrator pick a VID of her choice.
>
> Better to have default_pvid value propagated down. But, default_pvid is a
> per-bridge property, not a per-bridge-port property.
> RTM_SETLINK/RTM_GETLINK for PF_BRIDGE does have AFSPEC for per-bridge
> and PROTINFO for per-bridge-port, so it seems PVID needs to be part of
> AFSPEC.
I believe AFSPEC is not limited to per-bridge properties. It is per-bridge when the netlink msg's ifindex is that of a bridge and SELF flag is set.
AFSPEC is for a port when the netlink msg's ifindex is that of an enslaved port device and MASTER flag is set (or neither MASTER nor SELF flag is set)
PVID is one of the flags associated with a VID in bridge_vlan_info.
default_pvid is not currently supported by netlink. A new IFLA_BRIDGE_DEFAULT_PVID could be introduced to carry this property when a nlmsg is directed at a bridge.
>
> >However, it does not come via ndo_bridge_setlink. The proposed
> propagation at br_setlink or an up level one at rtnetlink are not capable of
> handling this case.
> > One possible way for handling that is to replace the call to
> >nbp_vlan_add with a call to a new function let's say int
> >br_propagate_vlan_add(struct net_bridge_port *port, u16 vid, u16 flags)
> This function will compose a netlink message with VLAN filtering information
> (i.e. AF_SPEC with VLAN_INFO) and call br_setlink - leveraging the offload
> support proposed by Roopa.
> >
> > If this is an acceptable course of action, I could work on such patch.
> >
> >
> >> -----Original Message-----
> >> From: netdev-owner@vger.kernel.org [mailto:netdev-
> >> owner@vger.kernel.org] On Behalf Of Arad, Ronen
> >> Sent: Friday, December 05, 2014 3:21 PM
> >> To: Roopa Prabhu; Scott Feldman; Netdev
> >> Cc: Jirí Pírko; Jamal Hadi Salim; Benjamin LaHaise; Thomas Graf; john
> >> fastabend; stephen@networkplumber.org; John Linville;
> >> nhorman@tuxdriver.com; Nicolas Dichtel; vyasevic@redhat.com; Florian
> >> Fainelli; buytenh@wantstofly.org; Aviad Raveh; David S. Miller;
> >> shm@cumulusnetworks.com; Andy Gospodarek
> >> Subject: RE: [PATCH 2/3] bridge: offload bridge port attributes to
> >> switch asic if feature flag set
> >>
> >>
> >>
<snip>
^ permalink raw reply
* Re: [PATCH v2 iproute] bridge link: add option 'self'
From: Roopa Prabhu @ 2014-12-06 8:03 UTC (permalink / raw)
To: Scott Feldman
Cc: Jiří Pírko, Jamal Hadi Salim, Benjamin LaHaise,
Thomas Graf, john fastabend, stephen@networkplumber.org,
John Linville, vyasevic@redhat.com, Netdev, David S. Miller, shm,
Andy Gospodarek
In-Reply-To: <CAE4R7bBYOW60bL07hD-wPWZZZxQ+jKx95cG0wnEMdU8KMZB5rw@mail.gmail.com>
On 12/5/14, 9:36 PM, Scott Feldman wrote:
> On Fri, Dec 5, 2014 at 4:59 PM, <roopa@cumulusnetworks.com> wrote:
>> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>>
>> Currently self is set internally only if hwmode is set.
>> This makes it necessary for the hw to have a mode.
>> There is no hwmode really required to go to hardware. So, introduce
>> self for anybody who wants to target hardware.
>>
>> v1 -> v2
>> - fix a few bugs. Initialize flags to zero: this was required to
>> keep the current behaviour unchanged.
>>
>> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
>> ---
>> bridge/link.c | 9 ++++++---
>> 1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/bridge/link.c b/bridge/link.c
>> index 90d9e7f..b8b8675 100644
>> --- a/bridge/link.c
>> +++ b/bridge/link.c
>> @@ -261,7 +261,7 @@ static int brlink_modify(int argc, char **argv)
>> __s16 priority = -1;
>> __s8 state = -1;
>> __s16 mode = -1;
>> - __u16 flags = BRIDGE_FLAGS_MASTER;
>> + __u16 flags = 0;
> I don't follow why this change is necessary. Seems defaulting to
> MASTER unless SELF is set due to "self" or "hwmode" would be more
> correct (and expected).
That flags initialization was always a no-op. IFLA_BRIDGE_FLAGS was
always set only with the 'self' flag on.
And i don't want to change that unnecessarily with my patch.
Setting it to master now means we will always include IFLA_AF_SPEC with
IFLA_BRIDGE_FLAGS in every 'bridge setlink' msg.
Which will be a change from the current behavior. And i dont intend to
introduce it with this patch.
Kernel has always treated no flags as 'master', so we are good from
kernel perspective.
>
>> struct rtattr *nest;
>>
>> memset(&req, 0, sizeof(req));
>> @@ -321,6 +321,8 @@ static int brlink_modify(int argc, char **argv)
>> "\"veb\".\n");
>> exit(-1);
>> }
>> + } else if (strcmp(*argv, "self") == 0) {
>> + flags = BRIDGE_FLAGS_SELF;
>> } else {
>> usage();
>> }
>> @@ -375,10 +377,11 @@ static int brlink_modify(int argc, char **argv)
>> * devices so far. Thus we only need to include the flags attribute
>> * if we are setting the hw mode.
>> */
> The comment above needs to be updated to reflect the new logic.
ok, will do, Thanks
>
>> - if (mode >= 0) {
>> + if (mode >= 0 || flags > 0) {
>> nest = addattr_nest(&req.n, sizeof(req), IFLA_AF_SPEC);
>>
>> - addattr16(&req.n, sizeof(req), IFLA_BRIDGE_FLAGS, flags);
>> + if (flags > 0)
>> + addattr16(&req.n, sizeof(req), IFLA_BRIDGE_FLAGS, flags);
>>
>> if (mode >= 0)
>> addattr16(&req.n, sizeof(req), IFLA_BRIDGE_MODE, mode);
>> --
>> 1.7.10.4
>>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/3] netdev: introduce new NETIF_F_HW_SWITCH_OFFLOAD feature flag for switch device offloads
From: Roopa Prabhu @ 2014-12-06 7:46 UTC (permalink / raw)
To: Thomas Graf
Cc: jiri, sfeldma, jhs, bcrl, john.fastabend, stephen, linville,
nhorman, nicolas.dichtel, vyasevic, f.fainelli, buytenh, aviadr,
netdev, davem, shm, gospo
In-Reply-To: <20141205224320.GA22992@casper.infradead.org>
On 12/5/14, 2:43 PM, Thomas Graf wrote:
> On 12/04/14 at 06:26pm, roopa@cumulusnetworks.com wrote:
>> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>>
>> This is a generic high level feature flag for all switch asic features today.
>>
>> switch drivers set this flag on switch ports. Logical devices like
>> bridge, bonds, vxlans can inherit this flag from their slaves/ports.
>>
>> I had to use SWITCH in the name to avoid ambiguity with other feature
>> flags. But, since i have been harping about not calling it 'switch',
>> I am welcome to any suggestions :)
>>
>> An alternative to using a feature flag is to use a IFF_HW_OFFLOAD
>> in net_device_flags.
> What does this flag indicate specifically? What driver would
> implement ndo_bridge_setlink() but not set this flag?
>
> I think it should be clearly documented when this flag is to bet set.
I mentioned it as an alternative because it was there in my RFC patch.
There is no code for it yet.
And I will get rid of the comment in v2.
^ permalink raw reply
* Re: [PATCH 2/3] bridge: offload bridge port attributes to switch asic if feature flag set
From: Scott Feldman @ 2014-12-06 6:54 UTC (permalink / raw)
To: Arad, Ronen
Cc: Roopa Prabhu, Netdev, Jirí Pírko, Jamal Hadi Salim,
Benjamin LaHaise, Thomas Graf, john fastabend,
stephen@networkplumber.org, John Linville, nhorman@tuxdriver.com,
Nicolas Dichtel, vyasevic@redhat.com, Florian Fainelli,
buytenh@wantstofly.org, Aviad Raveh, David S. Miller,
shm@cumulusnetworks.com, Andy Gospodarek
In-Reply-To: <E4CD12F19ABA0C4D8729E087A761DC3505D842BA@ORSMSX101.amr.corp.intel.com>
On Fri, Dec 5, 2014 at 3:21 PM, Arad, Ronen <ronen.arad@intel.com> wrote:
>
>
>> -----Original Message-----
>> From: netdev-owner@vger.kernel.org [mailto:netdev-
>> owner@vger.kernel.org] On Behalf Of Roopa Prabhu
>> Sent: Thursday, December 04, 2014 11:02 PM
>> To: Scott Feldman
>> Cc: Jiří Pírko; Jamal Hadi Salim; Benjamin LaHaise; Thomas Graf; john
>> fastabend; stephen@networkplumber.org; John Linville;
>> nhorman@tuxdriver.com; Nicolas Dichtel; vyasevic@redhat.com; Florian
>> Fainelli; buytenh@wantstofly.org; Aviad Raveh; Netdev; David S. Miller;
>> shm@cumulusnetworks.com; Andy Gospodarek
>> Subject: Re: [PATCH 2/3] bridge: offload bridge port attributes to switch asic
>> if feature flag set
>>
>> On 12/4/14, 10:41 PM, Scott Feldman wrote:
>> > On Thu, Dec 4, 2014 at 6:26 PM, <roopa@cumulusnetworks.com> wrote:
>> >> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>> >>
>> >> This allows offloading to switch asic without having the user to set
>> >> any flag. And this is done in the bridge driver to rollback kernel
>> >> settings on hw offload failure if required in the future.
>> >>
>> >> With this, it also makes sure a notification goes out only after the
>> >> attributes are set both in the kernel and hw.
>> > I like this approach as it streamlines the steps for the user in
>> > setting port flags. There is one case for FLOODING where you'll have
>> > to turn off flooding for both, and then turn on flooding in hw. You
>> > don't want flooding turned on on kernel and hw.
>> ok, maybe using the higher bits as in
>> https://patchwork.ozlabs.org/patch/413211/
>>
>> might help with that. Let me think some more.
>> >
>> >> ---
>> >> net/bridge/br_netlink.c | 27 ++++++++++++++++++++++++++-
>> >> 1 file changed, 26 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c index
>> >> 9f5eb55..ce173f0 100644
>> >> --- a/net/bridge/br_netlink.c
>> >> +++ b/net/bridge/br_netlink.c
>> >> @@ -407,9 +407,21 @@ int br_setlink(struct net_device *dev, struct
>> nlmsghdr *nlh)
>> >> afspec, RTM_SETLINK);
>> >> }
>> >>
>> >> + if ((dev->features & NETIF_F_HW_SWITCH_OFFLOAD) &&
>> >> + dev->netdev_ops->ndo_bridge_setlink) {
>> >> + int ret = dev->netdev_ops->ndo_bridge_setlink(dev,
>> >> + nlh);
>> > I think you want to up-level this to net/core/rtnetlink.c because
>> > you're only enabling the feature for one instance of a driver that
>> > implements ndo_bridge_setlink: the bridge driver. If another driver
>> > was MASTER and implemented ndo_bridge_setlink, you'd want same check
>> > to push setting down to SELF port driver.
>>
>> yeah, i thought about that. But i moved it here so that rollback would be
>> easier.
>
> There is a need for propagating setlink/dellink requests down multiple levels.
> The use-case I have in mind is a bridge at the top, team/bond in the middle, and port devices at the bottom.
> A setlink for VLAN filtering attributes would come with MASTER flag set, and either port or bond/team netdev.
> How would this be handled?
>
> The propagation rules between bridge and enslaved port device could be different from those between bond/team and enslaved devices.
> The current bridge driver does not propagate VLAN filtering from bridge to its ports as each port could have different configuration. In a case of a bond/team all members need to have the same configuration such that the a bond/team would be indistinguishable from a simple port.
>
> Therefore rtnetlink.c might not have the knowledge for propagation across multiple levels.
> It seems that each device which implements ndo_bridge_setlink/ndo_bridge_dellink and could have master role, need to take care of propagation to its slaves.
Thanks Ronen for bringing up this use-case of stacked masters. I
think for VLAN filtering, the stacked master case is handled, not by
ndo_setlink/dellink at each level, but with ndo_vlan_rx_kill_vid and
ndo_vlan_rx_add_vid. So the switch port driver can know VLAN
membership for port even if port is under bond which is under bridge,
by using ndo_vlan_rx_xxx and setting NETIF_F_HW_VLAN_CTAG_FILTER. The
bonding driver's ndo_vlan_rx_xxx handlers seem to keep ports in bond
VLAN membership consistent across bond.
But in general, ndo_setlink/dellink don't work for the stack use-case
for other non-VLAN attributes. Maybe the answer is to use the VLAN
propogation model for other attributes. ndo_setlink/dellink/getlink
have enough weird-isms it might be time to define cleaner ndo ops to
propagate the other attrs down.
^ permalink raw reply
* Re: [PATCH 2/3] bridge: offload bridge port attributes to switch asic if feature flag set
From: Scott Feldman @ 2014-12-06 6:29 UTC (permalink / raw)
To: Arad, Ronen
Cc: Roopa Prabhu, Netdev, Jirí Pírko, Jamal Hadi Salim,
Benjamin LaHaise, Thomas Graf, john fastabend,
stephen@networkplumber.org, John Linville, nhorman@tuxdriver.com,
Nicolas Dichtel, vyasevic@redhat.com, Florian Fainelli,
buytenh@wantstofly.org, Aviad Raveh, David S. Miller,
shm@cumulusnetworks.com, Andy Gospodarek
In-Reply-To: <E4CD12F19ABA0C4D8729E087A761DC3505D8436D@ORSMSX101.amr.corp.intel.com>
On Fri, Dec 5, 2014 at 5:04 PM, Arad, Ronen <ronen.arad@intel.com> wrote:
> I have another case of propagation which is not covered by the proposed patch.
> A recent patch introduced default_pvid attribute for a bridge (so far supported only via sysfs and not via netlink).
> When a port joins a bridge, it inherits a PVID from the default_pvid of the bridge.
> The bridge driver propagates that to the newly created net_bridge_port. This is done in br_vlan.c:
>
> int nbp_vlan_init(struct net_bridge_port *p)
> {
> int rc = 0;
>
> if (p->br->default_pvid) {
> rc = nbp_vlan_add(p, p->br->default_pvid,
> BRIDGE_VLAN_INFO_PVID |
> BRIDGE_VLAN_INFO_UNTAGGED);
> }
>
> return rc;
> }
>
> When L2 switching is offloaded to the HW, this PVID setting need to be propagated.
Agreed, it would be nice to have it propagated down, but there is a
non-ideal work-around. If you set default_pvid=0 to turn off PVID,
then the switch port driver can pick some internal VLAN ID just for HW
purposes in matching untagged pkts. It's non-ideal because the switch
port driver needs to reserve a block of VLAN IDs for internal usage or
use some other matching mechanism to keep untagged pkts within this
bridge.
Better to have default_pvid value propagated down. But, default_pvid
is a per-bridge property, not a per-bridge-port property.
RTM_SETLINK/RTM_GETLINK for PF_BRIDGE does have AFSPEC for per-bridge
and PROTINFO for per-bridge-port, so it seems PVID needs to be part of
AFSPEC.
>However, it does not come via ndo_bridge_setlink. The proposed propagation at br_setlink or an up level one at rtnetlink are not capable of handling this case.
> One possible way for handling that is to replace the call to nbp_vlan_add with a call to a new function let's say
> int br_propagate_vlan_add(struct net_bridge_port *port, u16 vid, u16 flags)
> This function will compose a netlink message with VLAN filtering information (i.e. AF_SPEC with VLAN_INFO) and call br_setlink - leveraging the offload support proposed by Roopa.
>
> If this is an acceptable course of action, I could work on such patch.
>
>
>> -----Original Message-----
>> From: netdev-owner@vger.kernel.org [mailto:netdev-
>> owner@vger.kernel.org] On Behalf Of Arad, Ronen
>> Sent: Friday, December 05, 2014 3:21 PM
>> To: Roopa Prabhu; Scott Feldman; Netdev
>> Cc: Jirí Pírko; Jamal Hadi Salim; Benjamin LaHaise; Thomas Graf; john
>> fastabend; stephen@networkplumber.org; John Linville;
>> nhorman@tuxdriver.com; Nicolas Dichtel; vyasevic@redhat.com; Florian
>> Fainelli; buytenh@wantstofly.org; Aviad Raveh; David S. Miller;
>> shm@cumulusnetworks.com; Andy Gospodarek
>> Subject: RE: [PATCH 2/3] bridge: offload bridge port attributes to switch asic
>> if feature flag set
>>
>>
>>
>> > -----Original Message-----
>> > From: netdev-owner@vger.kernel.org [mailto:netdev-
>> > owner@vger.kernel.org] On Behalf Of Roopa Prabhu
>> > Sent: Thursday, December 04, 2014 11:02 PM
>> > To: Scott Feldman
>> > Cc: Jiří Pírko; Jamal Hadi Salim; Benjamin LaHaise; Thomas Graf; john
>> > fastabend; stephen@networkplumber.org; John Linville;
>> > nhorman@tuxdriver.com; Nicolas Dichtel; vyasevic@redhat.com; Florian
>> > Fainelli; buytenh@wantstofly.org; Aviad Raveh; Netdev; David S.
>> > Miller; shm@cumulusnetworks.com; Andy Gospodarek
>> > Subject: Re: [PATCH 2/3] bridge: offload bridge port attributes to
>> > switch asic if feature flag set
>> >
>> > On 12/4/14, 10:41 PM, Scott Feldman wrote:
>> > > On Thu, Dec 4, 2014 at 6:26 PM, <roopa@cumulusnetworks.com> wrote:
>> > >> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>> > >>
>> > >> This allows offloading to switch asic without having the user to
>> > >> set any flag. And this is done in the bridge driver to rollback
>> > >> kernel settings on hw offload failure if required in the future.
>> > >>
>> > >> With this, it also makes sure a notification goes out only after
>> > >> the attributes are set both in the kernel and hw.
>> > > I like this approach as it streamlines the steps for the user in
>> > > setting port flags. There is one case for FLOODING where you'll
>> > > have to turn off flooding for both, and then turn on flooding in hw.
>> > > You don't want flooding turned on on kernel and hw.
>> > ok, maybe using the higher bits as in
>> > https://patchwork.ozlabs.org/patch/413211/
>> >
>> > might help with that. Let me think some more.
>> > >
>> > >> ---
>> > >> net/bridge/br_netlink.c | 27 ++++++++++++++++++++++++++-
>> > >> 1 file changed, 26 insertions(+), 1 deletion(-)
>> > >>
>> > >> diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
>> > >> index
>> > >> 9f5eb55..ce173f0 100644
>> > >> --- a/net/bridge/br_netlink.c
>> > >> +++ b/net/bridge/br_netlink.c
>> > >> @@ -407,9 +407,21 @@ int br_setlink(struct net_device *dev, struct
>> > nlmsghdr *nlh)
>> > >> afspec, RTM_SETLINK);
>> > >> }
>> > >>
>> > >> + if ((dev->features & NETIF_F_HW_SWITCH_OFFLOAD) &&
>> > >> + dev->netdev_ops->ndo_bridge_setlink) {
>> > >> + int ret = dev->netdev_ops->ndo_bridge_setlink(dev,
>> > >> + nlh);
>> > > I think you want to up-level this to net/core/rtnetlink.c because
>> > > you're only enabling the feature for one instance of a driver that
>> > > implements ndo_bridge_setlink: the bridge driver. If another driver
>> > > was MASTER and implemented ndo_bridge_setlink, you'd want same
>> check
>> > > to push setting down to SELF port driver.
>> >
>> > yeah, i thought about that. But i moved it here so that rollback would
>> > be easier.
>>
>> There is a need for propagating setlink/dellink requests down multiple levels.
>> The use-case I have in mind is a bridge at the top, team/bond in the middle,
>> and port devices at the bottom.
>> A setlink for VLAN filtering attributes would come with MASTER flag set, and
>> either port or bond/team netdev.
>> How would this be handled?
>>
>> The propagation rules between bridge and enslaved port device could be
>> different from those between bond/team and enslaved devices.
>> The current bridge driver does not propagate VLAN filtering from bridge to its
>> ports as each port could have different configuration. In a case of a
>> bond/team all members need to have the same configuration such that the a
>> bond/team would be indistinguishable from a simple port.
>>
>> Therefore rtnetlink.c might not have the knowledge for propagation across
>> multiple levels.
>> It seems that each device which implements
>> ndo_bridge_setlink/ndo_bridge_dellink and could have master role, need to
>> take care of propagation to its slaves.
>>
>> > >
>> > >> + if (ret && ret != -EOPNOTSUPP) {
>> > >> + /* XXX Fix this in the future to rollback
>> > >> + * kernel settings and return error
>> > >> + */
>> > > The future is now. Let's fix this now for the rollback case (again
>> > > up in rtnetlink.c). So then a general question comes to mind: for
>> > > these dual target sets, is it best to try HW first and then SW, or
>> > > the other way around? Either way, on failure on second you need to
>> > > rollback first. And, on failure, you need to know rollback value
>> > > for first, so you have to do a getlink on first before attempting set.
>> > yep, exactly, I went through the same thought process yesterday when i
>> > was trying to implement rollback.
>> > >
>> > >> + br_warn(p->br, "error offloading bridge attributes "
>> > >> + "on port %u(%s)\n", (unsigned int) p->port_no,
>> > >> + p->dev->name);
>> > >> + }
>> > >> + }
>> > >> +
>> > >> if (err == 0)
>> > >> br_ifinfo_notify(RTM_NEWLINK, p);
>> > >> -
>> > >> out:
>> > >> return err;
>> > >> }
>> > >> @@ -433,6 +445,19 @@ int br_dellink(struct net_device *dev, struct
>> > nlmsghdr *nlh)
>> > >> err = br_afspec((struct net_bridge *)netdev_priv(dev), p,
>> > >> afspec, RTM_DELLINK);
>> > >>
>> > >> + if (dev->features & NETIF_F_HW_SWITCH_OFFLOAD
>> > >> + && dev->netdev_ops->ndo_bridge_setlink) {
>> > >> + int ret = dev->netdev_ops->ndo_bridge_dellink(dev, nlh);
>> > >> + if (ret && ret != -EOPNOTSUPP) {
>> > >> + /* XXX Fix this in the future to rollback
>> > >> + * kernel settings and return error
>> > >> + */
>> > >> + br_warn(p->br, "error offloading bridge attributes "
>> > >> + "on port %u(%s)\n", (unsigned int) p->port_no,
>> > >> + p->dev->name);
>> > >> + }
>> > >> + }
>> > >> +
>> > > Same comments as setlink above.
>> > >
>> > >> return err;
>> > >> }
>> > >> static int br_validate(struct nlattr *tb[], struct nlattr
>> > >> *data[])
>> > >> --
>> > >> 1.7.10.4
>> > >>
>> >
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe netdev" in
>> > the body of a message to majordomo@vger.kernel.org More majordomo
>> info
>> > at http://vger.kernel.org/majordomo-info.html
>> {.n + +% lzwm b 맲 r zw u ^n r z h & G h ( 階 ݢj" m z ޖ
>> f h ~ m
^ permalink raw reply
* Re: [PATCH v2 net-next 0/6] allow eBPF programs to be attached to sockets
From: David Miller @ 2014-12-06 5:48 UTC (permalink / raw)
To: ast-uqk4Ao+rVK5Wk0Htik3J/w
Cc: mingo-DgEjT+Ai2ygdnm+yROfE0A, luto-kltTT9wpgjJwATOyAt5JVQ,
dborkman-H+wXaHxf7aLQT0dZR+AlfA,
hannes-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-api-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1417475199-15950-1-git-send-email-ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
From: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
Date: Mon, 1 Dec 2014 15:06:33 -0800
> V1->V2:
>
> fixed comments in sample code to state clearly that packet data is accessed
> with LD_ABS instructions and not internal skb fields.
> Also replaced constants in:
> BPF_LD_ABS(BPF_B, 14 + 9 /* R0 = ip->proto */),
> with:
> BPF_LD_ABS(BPF_B, ETH_HLEN + offsetof(struct iphdr, protocol) /* R0 = ip->proto */),
>
> V1 cover:
>
> Introduce BPF_PROG_TYPE_SOCKET_FILTER type of eBPF programs that can be
> attached to sockets with setsockopt().
> Allow such programs to access maps via lookup/update/delete helpers.
>
> This feature was previewed by bpf manpage in commit b4fc1a460f30("Merge branch 'bpf-next'")
> Now it can actually run.
>
> 1st patch adds LD_ABS/LD_IND instruction verification and
> 2nd patch adds new setsockopt() flag.
> Patches 3-6 are examples in assembler and in C.
>
> Though native eBPF programs are way more powerful than classic filters
> (attachable through similar setsockopt() call), they don't have skb field
> accessors yet. Like skb->pkt_type, skb->dev->ifindex are not accessible.
> There are sevaral ways to achieve that. That will be in the next set of patches.
> So in this set native eBPF programs can only read data from packet and
> access maps.
>
> The most powerful example is sockex2_kern.c from patch 6 where ~200 lines of C
> are compiled into ~300 of eBPF instructions.
> It shows how quite complex packet parsing can be done.
>
> LLVM used to build examples is at https://github.com/iovisor/llvm
> which is fork of llvm trunk that I'm cleaning up for upstreaming.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net] net/mlx4_en: correct the endianness of doorbell_qpn on big endian platform
From: Eric Dumazet @ 2014-12-06 5:46 UTC (permalink / raw)
To: David Miller; +Cc: weiyang, netdev, gideonn, edumazet, amirv
In-Reply-To: <20141205.213112.1199355931404701216.davem@davemloft.net>
On Fri, 2014-12-05 at 21:31 -0800, David Miller wrote:
> Guys, let's figure out what we are doing with this patch.
> --
Oh well, patch is fine, please apply it, thanks !
^ permalink raw reply
* Re: [PATCH V4 net-next] tun/macvtap: use consume_skb() instead of kfree_skb() when needed
From: David Miller @ 2014-12-06 5:45 UTC (permalink / raw)
To: jasowang; +Cc: netdev, linux-kernel, mst, eric.dumazet
In-Reply-To: <1417423995-4765-1-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Mon, 1 Dec 2014 16:53:15 +0800
> To be more friendly with drop monitor, we should only call kfree_skb() when
> the packets were dropped and use consume_skb() in other cases.
>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] rocker: remove swdev mode
From: Scott Feldman @ 2014-12-06 5:44 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Jiří Pírko, Jamal Hadi Salim, Benjamin LaHaise,
Thomas Graf, john fastabend, stephen@networkplumber.org,
John Linville, vyasevic@redhat.com, Netdev, David S. Miller, shm,
Andy Gospodarek
In-Reply-To: <1417828604-42722-3-git-send-email-roopa@cumulusnetworks.com>
On Fri, Dec 5, 2014 at 5:16 PM, <roopa@cumulusnetworks.com> wrote:
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> This resets rocker mode to zero (vepa) during gets.
> This is because the default getlink handler that rocker
> uses today always takes a mode.
>
> Will fix that in a subsequent patch.
One patch set with that fix would be better, otherwise your patch here
will show rocker port running in VEB mode, which is wrong. Maybe
return mode=-1 for unspecified, or something like that?
>
> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
> ---
> drivers/net/ethernet/rocker/rocker.c | 18 +-----------------
> 1 file changed, 1 insertion(+), 17 deletions(-)
>
> diff --git a/drivers/net/ethernet/rocker/rocker.c b/drivers/net/ethernet/rocker/rocker.c
> index fded127..391077c 100644
> --- a/drivers/net/ethernet/rocker/rocker.c
> +++ b/drivers/net/ethernet/rocker/rocker.c
> @@ -3700,27 +3700,11 @@ static int rocker_port_bridge_setlink(struct net_device *dev,
> {
> struct rocker_port *rocker_port = netdev_priv(dev);
> struct nlattr *protinfo;
> - struct nlattr *afspec;
> struct nlattr *attr;
> - u16 mode;
> int err;
>
> protinfo = nlmsg_find_attr(nlh, sizeof(struct ifinfomsg),
> IFLA_PROTINFO);
> - afspec = nlmsg_find_attr(nlh, sizeof(struct ifinfomsg), IFLA_AF_SPEC);
> -
> - if (afspec) {
> - attr = nla_find_nested(afspec, IFLA_BRIDGE_MODE);
> - if (attr) {
> - if (nla_len(attr) < sizeof(mode))
> - return -EINVAL;
> -
> - mode = nla_get_u16(attr);
> - if (mode != BRIDGE_MODE_SWDEV)
> - return -EINVAL;
> - }
> - }
> -
> if (protinfo) {
> attr = nla_find_nested(protinfo, IFLA_BRPORT_LEARNING);
> if (attr) {
> @@ -3755,7 +3739,7 @@ static int rocker_port_bridge_getlink(struct sk_buff *skb, u32 pid, u32 seq,
> u32 filter_mask)
> {
> struct rocker_port *rocker_port = netdev_priv(dev);
> - u16 mode = BRIDGE_MODE_SWDEV;
> + u16 mode = 0;
> u32 mask = BR_LEARNING | BR_LEARNING_SYNC;
>
> return ndo_dflt_bridge_getlink(skb, pid, seq, dev, mode,
> --
> 1.7.10.4
>
^ permalink raw reply
* Re: [PATCH net] openvswitch: Fix flow mask validation.
From: David Miller @ 2014-12-06 5:42 UTC (permalink / raw)
To: pshelar; +Cc: netdev
In-Reply-To: <1417417457-1492-1-git-send-email-pshelar@nicira.com>
From: Pravin B Shelar <pshelar@nicira.com>
Date: Sun, 30 Nov 2014 23:04:17 -0800
> Following patch fixes typo in the flow validation. This prevented
> installation of ARP and IPv6 flows.
>
> Fixes: 19e7a3df72 ("openvswitch: Fix NDP flow mask validation")
> Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH v2 iproute] bridge link: add option 'self'
From: Scott Feldman @ 2014-12-06 5:36 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Jiří Pírko, Jamal Hadi Salim, Benjamin LaHaise,
Thomas Graf, john fastabend, stephen@networkplumber.org,
John Linville, vyasevic@redhat.com, Netdev, David S. Miller, shm,
Andy Gospodarek
In-Reply-To: <1417827563-811-1-git-send-email-roopa@cumulusnetworks.com>
On Fri, Dec 5, 2014 at 4:59 PM, <roopa@cumulusnetworks.com> wrote:
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> Currently self is set internally only if hwmode is set.
> This makes it necessary for the hw to have a mode.
> There is no hwmode really required to go to hardware. So, introduce
> self for anybody who wants to target hardware.
>
> v1 -> v2
> - fix a few bugs. Initialize flags to zero: this was required to
> keep the current behaviour unchanged.
>
> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
> ---
> bridge/link.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/bridge/link.c b/bridge/link.c
> index 90d9e7f..b8b8675 100644
> --- a/bridge/link.c
> +++ b/bridge/link.c
> @@ -261,7 +261,7 @@ static int brlink_modify(int argc, char **argv)
> __s16 priority = -1;
> __s8 state = -1;
> __s16 mode = -1;
> - __u16 flags = BRIDGE_FLAGS_MASTER;
> + __u16 flags = 0;
I don't follow why this change is necessary. Seems defaulting to
MASTER unless SELF is set due to "self" or "hwmode" would be more
correct (and expected).
> struct rtattr *nest;
>
> memset(&req, 0, sizeof(req));
> @@ -321,6 +321,8 @@ static int brlink_modify(int argc, char **argv)
> "\"veb\".\n");
> exit(-1);
> }
> + } else if (strcmp(*argv, "self") == 0) {
> + flags = BRIDGE_FLAGS_SELF;
> } else {
> usage();
> }
> @@ -375,10 +377,11 @@ static int brlink_modify(int argc, char **argv)
> * devices so far. Thus we only need to include the flags attribute
> * if we are setting the hw mode.
> */
The comment above needs to be updated to reflect the new logic.
> - if (mode >= 0) {
> + if (mode >= 0 || flags > 0) {
> nest = addattr_nest(&req.n, sizeof(req), IFLA_AF_SPEC);
>
> - addattr16(&req.n, sizeof(req), IFLA_BRIDGE_FLAGS, flags);
> + if (flags > 0)
> + addattr16(&req.n, sizeof(req), IFLA_BRIDGE_FLAGS, flags);
>
> if (mode >= 0)
> addattr16(&req.n, sizeof(req), IFLA_BRIDGE_MODE, mode);
> --
> 1.7.10.4
>
^ permalink raw reply
* Re: [PATCH] uapi: fix to export linux/vm_sockets.h
From: David Miller @ 2014-12-06 5:36 UTC (permalink / raw)
To: yamada.m-NAum8xwdG0+S7A1Ibl2khg
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
ast-uqk4Ao+rVK5Wk0Htik3J/w, piotr.krol-zILERgsGILsAvxtiuMwx3w,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
sakari.ailus-VuQAYsv1563Yd54FQh9/CA,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1417396577-32499-1-git-send-email-yamada.m-NAum8xwdG0+S7A1Ibl2khg@public.gmane.org>
From: Masahiro Yamada <yamada.m-NAum8xwdG0+S7A1Ibl2khg@public.gmane.org>
Date: Mon, 1 Dec 2014 10:16:17 +0900
> A typo "header=y" was introduced by commit 7071cf7fc435
> (uapi: add missing network related headers to kbuild).
>
> Signed-off-by: Masahiro Yamada <yamada.m-NAum8xwdG0+S7A1Ibl2khg@public.gmane.org>
> Cc: Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
Applied.
^ permalink raw reply
* Re: [PATCH] sky2: avoid pci write posting after disabling irqs
From: David Miller @ 2014-12-06 5:34 UTC (permalink / raw)
To: LinoSanfilippo; +Cc: stephen, mlindner, netdev, linux-kernel
In-Reply-To: <1417348611-1752-1-git-send-email-LinoSanfilippo@gmx.de>
From: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Date: Sun, 30 Nov 2014 12:56:51 +0100
> In sky2_change_mtu setting B0_IMSK to 0 may be delayed due to PCI write posting
> which could result in irqs being still active when synchronize_irq is called.
> Since we are not prepared to handle any further irqs after synchronize_irq
> (our resources are freed after that) force the write by a consecutive read from
> the same register.
> Similar situation in sky2_all_down: Here we disabled irqs by a write to B0_IMSK
> but did not ensure that this write took place before synchronize_irq. Fix that
> too.
>
> Signed-off-by: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Applied.
^ permalink raw reply
* Re: [PATCH] skge: Unmask interrupts in case of spurious interrupts
From: David Miller @ 2014-12-06 5:34 UTC (permalink / raw)
To: LinoSanfilippo; +Cc: stephen, mlindner, netdev, linux-kernel
In-Reply-To: <1417348291-1302-1-git-send-email-LinoSanfilippo@gmx.de>
From: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Date: Sun, 30 Nov 2014 12:51:31 +0100
> In case of a spurious interrupt dont forget to reenable the interrupts that
> have been masked by reading the interrupt source register.
>
> Signed-off-by: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Applied.
^ permalink raw reply
* Re: [PATCH] pxa168: close race between napi and irq activation
From: David Miller @ 2014-12-06 5:34 UTC (permalink / raw)
To: LinoSanfilippo
Cc: arnd, paul.gortmaker, w-lkml, f.fainelli, netdev, linux-kernel
In-Reply-To: <1417344576-4940-1-git-send-email-LinoSanfilippo@gmx.de>
From: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Date: Sun, 30 Nov 2014 11:49:36 +0100
> In pxa168_eth_open() the irqs are enabled before napi. This opens a tiny time
> window in which the irq handler is processed, disables irqs but then is not able
> to schedule the not yet activated napi, leaving irqs disabled forever (since
> irqs are reenabled in napi poll function).
> Fix this race by activating napi before irqs are activated.
>
> Signed-off-by: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Applied.
^ permalink raw reply
* Re: [PATCH net] net/mlx4_en: correct the endianness of doorbell_qpn on big endian platform
From: David Miller @ 2014-12-06 5:31 UTC (permalink / raw)
To: weiyang; +Cc: netdev, gideonn, edumazet, amirv
In-Reply-To: <1417315431-16761-1-git-send-email-weiyang@linux.vnet.ibm.com>
From: Wei Yang <weiyang@linux.vnet.ibm.com>
Date: Sun, 30 Nov 2014 10:43:51 +0800
> In commit 6a4e812 (net/mlx4_en: Avoid calling bswap in tx fast path), we store
> doorbell_qpn in big endian to avoid bswap(). Then we try to write it directly
> by iowrite32() instead of iowrite32be().
>
> This works fine on little endian platform, while has some problem on big
> endian platform. Here is the definition in general:
>
> #define iowrite32(v, addr) writel((v), (addr))
> #define writel(b,addr) __raw_writel(__cpu_to_le32(b),addr)
>
> On little endian platform, the value is not swapped before write. While on big
> endian platform, the value is swapped. This is not expected to happen.
>
> This patch does the swap on big endian platform before it is written.
>
> Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Guys, let's figure out what we are doing with this patch.
^ permalink raw reply
* Re: [PATCH v2 net] bpf: x86: fix epilogue generation for eBPF programs
From: David Miller @ 2014-12-06 5:24 UTC (permalink / raw)
To: ast; +Cc: zlim.lnx, edumazet, dborkman, hpa, tglx, mingo, netdev,
linux-kernel
In-Reply-To: <1417301173-23691-1-git-send-email-ast@plumgrid.com>
From: Alexei Starovoitov <ast@plumgrid.com>
Date: Sat, 29 Nov 2014 14:46:13 -0800
> classic BPF has a restriction that last insn is always BPF_RET.
> eBPF doesn't have BPF_RET instruction and this restriction.
> It has BPF_EXIT insn which can appear anywhere in the program
> one or more times and it doesn't have to be last insn.
> Fix eBPF JIT to emit epilogue when first BPF_EXIT is seen
> and all other BPF_EXIT instructions will be emitted as jump.
>
> Since jump offset to epilogue is computed as:
> jmp_offset = ctx->cleanup_addr - addrs[i]
> we need to change type of cleanup_addr to signed to compute the offset as:
> (long long) ((int)20 - (int)30)
> instead of:
> (long long) ((unsigned int)20 - (int)30)
>
> Fixes: 622582786c9e ("net: filter: x86: internal BPF JIT")
> Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/1] net-PA Semi: Deletion of unnecessary checks before the function call "pci_dev_put"
From: David Miller @ 2014-12-06 5:15 UTC (permalink / raw)
To: elfring; +Cc: olof, netdev, linux-kernel, kernel-janitors, julia.lawall
In-Reply-To: <547A09B1.9090102@users.sourceforge.net>
From: SF Markus Elfring <elfring@users.sourceforge.net>
Date: Sat, 29 Nov 2014 19:00:17 +0100
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sat, 29 Nov 2014 18:55:40 +0100
>
> The pci_dev_put() function tests whether its argument is NULL
> and then returns immediately. Thus the test around the call
> is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Applied.
^ permalink raw reply
* Re: [PATCH 1/1] net: cassini: Deletion of an unnecessary check before the function call "vfree"
From: David Miller @ 2014-12-06 5:14 UTC (permalink / raw)
To: elfring; +Cc: netdev, linux-kernel, kernel-janitors, cocci
In-Reply-To: <5479D2AD.9060704@users.sourceforge.net>
From: SF Markus Elfring <elfring@users.sourceforge.net>
Date: Sat, 29 Nov 2014 15:05:33 +0100
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sat, 29 Nov 2014 14:34:59 +0100
>
> The vfree() function performs also input parameter validation.
> Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Applied.
^ permalink raw reply
* Re: [PATCH 1/1] net-ipvlan: Deletion of an unnecessary check before the function call "free_percpu"
From: David Miller @ 2014-12-06 5:14 UTC (permalink / raw)
To: elfring; +Cc: netdev, linux-kernel, kernel-janitors, julia.lawall
In-Reply-To: <5479E693.3010200@users.sourceforge.net>
From: SF Markus Elfring <elfring@users.sourceforge.net>
Date: Sat, 29 Nov 2014 16:30:27 +0100
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sat, 29 Nov 2014 16:23:20 +0100
>
> The free_percpu() function tests whether its argument is NULL and then
> returns immediately. Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Applied.
^ permalink raw reply
* Re: [PATCH] stmmac: pci: allocate memory resources dynamically
From: David Miller @ 2014-12-06 5:04 UTC (permalink / raw)
To: andriy.shevchenko
Cc: peppe.cavallaro, netdev, hock.leong.kweh, vbridgers2013, rayagond
In-Reply-To: <1417182056-17650-1-git-send-email-andriy.shevchenko@linux.intel.com>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Fri, 28 Nov 2014 15:40:56 +0200
> Instead of using global variables we are going to use dynamically allocated
> memory. It allows to append a support of more than one ethernet adapter which
> might have different settings simultaniously.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 00/12] Netfilter updates for net-next
From: David Miller @ 2014-12-06 4:58 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1417611342-25257-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Wed, 3 Dec 2014 13:55:30 +0100
> The following batch contains netfilter updates for net-next. Basically,
> enhancements for xt_recent, skip zeroing of timer in conntrack, fix
> linking problem with recent redirect support for nf_tables, ipset
> updates and a couple of cleanups. More specifically, they are:
...
> You can pull these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git
>
> Thanks!
Pulled, thanks a lot Pablo.
^ permalink raw reply
* Re: [net-next 04/14] ixgbe: remove CIAA/D register reads from bad VF check
From: Jeff Kirsher @ 2014-12-06 4:58 UTC (permalink / raw)
To: David Miller
Cc: emil.s.tantilov, netdev, nhorman, sassmann, jogreene,
alex.williamson
In-Reply-To: <20141205.204956.1468623374943582606.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]
On Fri, 2014-12-05 at 20:49 -0800, David Miller wrote:
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Fri, 5 Dec 2014 09:52:43 -0800
>
> > From: Emil Tantilov <emil.s.tantilov@intel.com>
> >
> > Accessing the CIAA/D register can block access to the PCI config space.
> >
> > This patch removes the read/write operations to the CIAA/D registers
> > and makes use of standard kernel functions for accessing the PCI config
> > space.
> >
> > In addition it moves ixgbevf_check_for_bad_vf() into the watchdog subtask
> > which reduces the frequency of the checks.
> >
> > CC: Alex Williamson <alex.williamson@redhat.com>
> > Reported-by: Alex Williamson <alex.williamson@redhat.com>
> > Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
> > Tested-by: Aaron Brown <aaron.f.brown@intel.com>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>
> Alex Willaimson stated that he'd like to see this for -stable, but I'm warning
> right now that a change not appropriate for 'net' is not approperiate for
> '-stable' either.
Agreed, only reason I did not send this to net (along with the other
fixes by Emil) was that we are at -rc7 and do not consider these
"critical" to try and squeeze in before the release.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [net-next 00/14][pull request] Intel Wired LAN Driver Updates 2014-12-05
From: David Miller @ 2014-12-06 4:55 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <1417801973-28793-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 5 Dec 2014 09:52:39 -0800
> This series contains updates to ixgbe and ixgbevf.
...
> The following are changes since commit d8febb77b52ebddb9bd03ccaa5b61005e3a45a85:
> tun: Fix GSO meta-data handling in tun_get_user
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [net-next 04/14] ixgbe: remove CIAA/D register reads from bad VF check
From: David Miller @ 2014-12-06 4:49 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: emil.s.tantilov, netdev, nhorman, sassmann, jogreene,
alex.williamson
In-Reply-To: <1417801973-28793-5-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 5 Dec 2014 09:52:43 -0800
> From: Emil Tantilov <emil.s.tantilov@intel.com>
>
> Accessing the CIAA/D register can block access to the PCI config space.
>
> This patch removes the read/write operations to the CIAA/D registers
> and makes use of standard kernel functions for accessing the PCI config
> space.
>
> In addition it moves ixgbevf_check_for_bad_vf() into the watchdog subtask
> which reduces the frequency of the checks.
>
> CC: Alex Williamson <alex.williamson@redhat.com>
> Reported-by: Alex Williamson <alex.williamson@redhat.com>
> Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Alex Willaimson stated that he'd like to see this for -stable, but I'm warning
right now that a change not appropriate for 'net' is not approperiate for
'-stable' either.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox