* Add support for D-Link 530T rev C1 (Kernel Bug 38862)
From: Lennart Sorensen @ 2011-07-28 23:18 UTC (permalink / raw)
To: netdev
Cc: Len Sorensen, linux-kernel, Realtek linux nic maintainers,
Francois Romieu, drivers_network
The D-Link DGE-530T rev C1 is a re-badged Realtek 8169 named DLG10028C,
unlike the previous revisions which were skge based. It is probably
the same as the discontinued DGE-528T (0x4300) other than the PCI ID.
The PCI ID is 0x1186:0x4302.
Adding it to r8169.c where 0x1186:0x4300 is already found makes the card
be detected and work.
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=38862
Signed-off-by: Len Sorensen <lsorense@csclub.uwaterloo.ca>
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 7d9c650..c77286e 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -239,6 +239,7 @@ static DEFINE_PCI_DEVICE_TABLE(rtl8169_pci_tbl) = {
{ PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8168), 0, 0, RTL_CFG_1 },
{ PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8169), 0, 0, RTL_CFG_0 },
{ PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4300), 0, 0, RTL_CFG_0 },
+ { PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4302), 0, 0, RTL_CFG_0 },
{ PCI_DEVICE(PCI_VENDOR_ID_AT, 0xc107), 0, 0, RTL_CFG_0 },
{ PCI_DEVICE(0x16ec, 0x0116), 0, 0, RTL_CFG_0 },
{ PCI_VENDOR_ID_LINKSYS, 0x1032,
--
Len Sorensen
^ permalink raw reply related
* RE: [RFC net-next PATCH 3/4] ethtool: Add new set commands
From: Rose, Gregory V @ 2011-07-28 22:25 UTC (permalink / raw)
To: Ben Hutchings
Cc: netdev@vger.kernel.org, davem@davemloft.net, Kirsher, Jeffrey T
In-Reply-To: <1311890667.2677.22.camel@deadeye>
> -----Original Message-----
> From: Ben Hutchings [mailto:bhutchings@solarflare.com]
> Sent: Thursday, July 28, 2011 3:04 PM
> To: Rose, Gregory V
> Cc: netdev@vger.kernel.org; davem@davemloft.net; Kirsher, Jeffrey T
> Subject: RE: [RFC net-next PATCH 3/4] ethtool: Add new set commands
>
> On Thu, 2011-07-28 at 14:34 -0700, Rose, Gregory V wrote:
> > > -----Original Message-----
> > > From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org]
> > > On Behalf Of Ben Hutchings
> > > Sent: Thursday, July 28, 2011 2:20 PM
> > > To: Rose, Gregory V
> > > Cc: netdev@vger.kernel.org; davem@davemloft.net; Kirsher, Jeffrey T
> > > Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
> > >
> > > On Wed, 2011-07-27 at 15:17 -0700, Greg Rose wrote:
> > > > Add new set commands to configure the number of SR-IOV VFs, the
> > > > number of VM queues and spoof checking on/off switch.
> > > >
> > > > Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> > > > ---
> > > >
> > > > include/linux/ethtool.h | 11 ++++++++++-
> > > > 1 files changed, 10 insertions(+), 1 deletions(-)
> > > >
> > > > diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> > > > index c6e427a..c4972ba 100644
> > > > --- a/include/linux/ethtool.h
> > > > +++ b/include/linux/ethtool.h
> > > > @@ -36,12 +36,14 @@ struct ethtool_cmd {
> > > > __u8 mdio_support;
> > > > __u32 maxtxpkt; /* Tx pkts before generating tx int */
> > > > __u32 maxrxpkt; /* Rx pkts before generating rx int */
> > > > + __u32 num_vfs; /* Enable SR-IOV VFs */
> > >
> > > What are the semantics of changing this after VFs have already been
> set
> > > up?
> >
> > There's an example of it patch 4/4 in this set. The PF driver checks
> > if any VFs are assigned and active and if not then it will disable and
> > destroy all the current VFs via a call to pci_disable_sriov() and then
> > call pci_enable_sriov() with the new number of VFs. Or, if the number
> > of new VFs is zero then SR-IOV is left disabled on that PF.
>
> And otherwise the request fails?
Yes, it returns -EBUSY if VFs are in use (assigned to guest VMs) or the PF driver is up and running. It can return other errors from the post configuration setup of interrupt resources.
>
> > Mostly this is to accommodate customer requests to be able to set a
> > different number of VFs per PF or to only have specified PFs enable
> > VFs. The current usage of the max_vfs module parameter is unwieldy in
> > this sense as you must enable SR-IOV VFs on all physical functions
> > found during the device probe with the same number of VFs.
>
> Right, this makes a lot of sense.
>
> > > > + __u32 num_vmqs; /* Set number of queues for VMDq */
> > >
> > > VMDq is an Intel proprietary name. Please specify this in generic
> > > terms.
> >
> > I'll use the more generic term VM queues.
> [...]
>
> Still ambiguous. I think what you actually intend is that this will be
> the number of RX queues and the number of TX queues per VF. Right?
> You might want to allow for different numbers of RX and TX queues.
OK, that's not a problem. Our devices only support matching numbers of queue pairs but I suppose other devices might have the ability to have different numbers of Rx/Tx queues per VF. I'll rework it that way while I'm adding the new command.
The number of queues might also be used in a scenario similar to the VMware Net Queues (TM) feature. There is no support for that in Linux at the moment but it could be supported in the future.
- Greg
^ permalink raw reply
* drivers/net/tun.c: CAP_NET_ADMIN conditional not reached
From: Petar Bogdanovic @ 2011-07-28 22:00 UTC (permalink / raw)
To: netdev
Hi,
drivers/net/tun.c says:
1004 if (((tun->owner != -1 && cred->euid != tun->owner) ||
1005 (tun->group != -1 && !in_egroup_p(tun->group))) &&
1006 !capable(CAP_NET_ADMIN))
1007 return -EPERM;
this will skip !capable(CAP_NET_ADMIN) if tun->owner and tun->group are
both -1, which seems to be their default value (see lines 854,855).
ip(8) from iproute2 won't do any TUNSETOWNER/TUNSETGROUP ioctl() if no
uid and/or gid is supplied so when using `ip tuntap' as an unprivileged
user, you'll be unable to create a new tun(4) but won't have any
problems attaching to an existing device created without both user and
group options.
I'm not sure whether this is intentional since it has been around for
years.. although triggering it with tunctl(8) was not possible---tunctl
without `-u' seems to use 0 as the default value for TUNSETOWNER.
Petar Bogdanovic
^ permalink raw reply
* RE: [RFC net-next PATCH 3/4] ethtool: Add new set commands
From: Ben Hutchings @ 2011-07-28 22:04 UTC (permalink / raw)
To: Rose, Gregory V
Cc: netdev@vger.kernel.org, davem@davemloft.net, Kirsher, Jeffrey T
In-Reply-To: <43F901BD926A4E43B106BF17856F0755019414D910@orsmsx508.amr.corp.intel.com>
On Thu, 2011-07-28 at 14:34 -0700, Rose, Gregory V wrote:
> > -----Original Message-----
> > From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> > On Behalf Of Ben Hutchings
> > Sent: Thursday, July 28, 2011 2:20 PM
> > To: Rose, Gregory V
> > Cc: netdev@vger.kernel.org; davem@davemloft.net; Kirsher, Jeffrey T
> > Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
> >
> > On Wed, 2011-07-27 at 15:17 -0700, Greg Rose wrote:
> > > Add new set commands to configure the number of SR-IOV VFs, the
> > > number of VM queues and spoof checking on/off switch.
> > >
> > > Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> > > ---
> > >
> > > include/linux/ethtool.h | 11 ++++++++++-
> > > 1 files changed, 10 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> > > index c6e427a..c4972ba 100644
> > > --- a/include/linux/ethtool.h
> > > +++ b/include/linux/ethtool.h
> > > @@ -36,12 +36,14 @@ struct ethtool_cmd {
> > > __u8 mdio_support;
> > > __u32 maxtxpkt; /* Tx pkts before generating tx int */
> > > __u32 maxrxpkt; /* Rx pkts before generating rx int */
> > > + __u32 num_vfs; /* Enable SR-IOV VFs */
> >
> > What are the semantics of changing this after VFs have already been set
> > up?
>
> There's an example of it patch 4/4 in this set. The PF driver checks
> if any VFs are assigned and active and if not then it will disable and
> destroy all the current VFs via a call to pci_disable_sriov() and then
> call pci_enable_sriov() with the new number of VFs. Or, if the number
> of new VFs is zero then SR-IOV is left disabled on that PF.
And otherwise the request fails?
> Mostly this is to accommodate customer requests to be able to set a
> different number of VFs per PF or to only have specified PFs enable
> VFs. The current usage of the max_vfs module parameter is unwieldy in
> this sense as you must enable SR-IOV VFs on all physical functions
> found during the device probe with the same number of VFs.
Right, this makes a lot of sense.
> > > + __u32 num_vmqs; /* Set number of queues for VMDq */
> >
> > VMDq is an Intel proprietary name. Please specify this in generic
> > terms.
>
> I'll use the more generic term VM queues.
[...]
Still ambiguous. I think what you actually intend is that this will be
the number of RX queues and the number of TX queues per VF. Right?
You might want to allow for different numbers of RX and TX queues.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* RE: [RFC net-next PATCH 3/4] ethtool: Add new set commands
From: Rose, Gregory V @ 2011-07-28 22:04 UTC (permalink / raw)
To: Anirban Chakraborty
Cc: David Miller, netdev, Ben Hutchings, Kirsher, Jeffrey T,
virtualization@lists.linux-foundation.org
In-Reply-To: <789BE5A3-93DF-4869-A0AF-180AA86F4AC6@qlogic.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Anirban Chakraborty
> Sent: Thursday, July 28, 2011 3:01 PM
> To: Rose, Gregory V
> Cc: David Miller; netdev; Ben Hutchings; Kirsher, Jeffrey T;
> virtualization@lists.linux-foundation.org
> Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
>
>
> On Jul 28, 2011, at 1:38 PM, Rose, Gregory V wrote:
>
> >
> >> From: Anirban Chakraborty [mailto:anirban.chakraborty@qlogic.com]
> >> Sent: Thursday, July 28, 2011 12:04 PM
> >> To: Rose, Gregory V
> >> Cc: David Miller; netdev; Ben Hutchings; Kirsher, Jeffrey T
> >> Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
> >>
> >>
> >> If I understood it correctly, you are trying to set/unset spoofing on
> per
> >> eth interface, which could be a PF on the hypervisor or a pci
> passthru-ed
> >> VF in the linux guest. There are other security features that one
> could set
> >> for a port on the VF (lets call it vport), e.g. setting a port VLAN ID
> for
> >> a VF and specifying if the VF (VM) is allowed to send tagged/untagged
> >> packets, setting a vport in port mirroring mode so that the PF can
> monitor
> >> the traffic on a VF, setting a vport in promiscuous mode etc.
> >>
> >> Does it make sense to try to use ip link util to specify all these
> parameters,
> >> since ip link already does the job of setting VF properties and VF
> port
> >> profile?
> >>
> >> Any thoughts?
> >>
> >
> > Sure, that's a possibility too. I was considering ethtool for this
> since MAC addresses and VLANs are fairly specific to Ethernet whereas
> netlink might apply to other types of physical networks. At least that's
> my understanding.
>
> You could specify VF MAC and VLANs using netlink today.
> e.g. ip link set ethX vf # mac, vlan etc.
> Adding spoofing as follows would do it.
> ip link set ethX vf # spoof on|off
>
> Having SR-IOV features scattered among ethtool and ip link may be
> inconvenient for the end users.
> CC-ing virtualization list.
>
> >
> > However, I have no strong feelings about it and if community consensus
> is to use ip link instead then that's fine by me.
> >
> > Of course, patches implementing such would be quite welcome also.
>
> I could take a stab at it at the netlink side, if there is a consensus.
Now that I think about it I'm seeing it more your way. I'll drop the anti-spoofing stuff from my ethtool patches. If you get the time to provide patches to netlink for anti-spoofing then that's great, otherwise I'll do it when I get done with the SR-IOV reconfig stuff.
Thanks,
- Greg
^ permalink raw reply
* Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
From: Anirban Chakraborty @ 2011-07-28 22:01 UTC (permalink / raw)
To: Rose, Gregory V
Cc: David Miller, netdev, Ben Hutchings, Kirsher, Jeffrey T,
virtualization@lists.linux-foundation.org
In-Reply-To: <43F901BD926A4E43B106BF17856F0755019414D86D@orsmsx508.amr.corp.intel.com>
On Jul 28, 2011, at 1:38 PM, Rose, Gregory V wrote:
>
>> From: Anirban Chakraborty [mailto:anirban.chakraborty@qlogic.com]
>> Sent: Thursday, July 28, 2011 12:04 PM
>> To: Rose, Gregory V
>> Cc: David Miller; netdev; Ben Hutchings; Kirsher, Jeffrey T
>> Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
>>
>>
>> On Jul 28, 2011, at 8:51 AM, Rose, Gregory V wrote:
>>
>>
>> -----Original Message-----
>> From: David Miller [mailto:davem@davemloft.net]
>> Sent: Wednesday, July 27, 2011 10:28 PM
>> To: Rose, Gregory V
>> Cc: netdev@vger.kernel.org; bhutchings@solarflare.com; Kirsher, Jeffrey T
>> Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
>>
>> From: Greg Rose <gregory.v.rose@intel.com>
>> Date: Wed, 27 Jul 2011 15:17:59 -0700
>>
>> Add new set commands to configure the number of SR-IOV VFs, the
>> number of VM queues and spoof checking on/off switch.
>>
>> Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
>> ---
>>
>> include/linux/ethtool.h | 11 ++++++++++-
>> 1 files changed, 10 insertions(+), 1 deletions(-)
>>
>> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
>> index c6e427a..c4972ba 100644
>> --- a/include/linux/ethtool.h
>> +++ b/include/linux/ethtool.h
>> @@ -36,12 +36,14 @@ struct ethtool_cmd {
>> __u8 mdio_support;
>> __u32 maxtxpkt; /* Tx pkts before generating tx int */
>> __u32 maxrxpkt; /* Rx pkts before generating rx int */
>> + __u32 num_vfs; /* Enable SR-IOV VFs */
>> + __u32 num_vmqs; /* Set number of queues for VMDq */
>>
>> You can't change the layout of this datastructure in this way without
>> breaking every ethtool binary out there.
>>
>> You have to find another place to add these knobs.
>>
>> Perhaps at the end of the ethtool_cmd structure? Something like this:
>>
>> /* This should work for both 32 and 64 bit userland. */
>> struct ethtool_cmd {
>> __u32 cmd;
>> __u32 supported; /* Features this interface supports */
>> __u32 advertising; /* Features this interface advertises */
>> __u16 speed; /* The forced speed (lower bits) in
>> * Mbps. Please use
>> * ethtool_cmd_speed()/_set() to
>> * access it */
>> __u8 duplex; /* Duplex, half or full */
>> __u8 port; /* Which connector port */
>> __u8 phy_address;
>> __u8 transceiver; /* Which transceiver to use */
>> __u8 autoneg; /* Enable or disable autonegotiation */
>> __u8 mdio_support;
>> __u32 maxtxpkt; /* Tx pkts before generating tx int */
>> __u32 maxrxpkt; /* Rx pkts before generating rx int */
>> __u16 speed_hi; /* The forced speed (upper
>> * bits) in Mbps. Please use
>> * ethtool_cmd_speed()/_set() to
>> * access it */
>> __u8 eth_tp_mdix;
>> __u8 spoof_check; /* Enable/Disable anti-spoofing */
>> __u32 lp_advertising; /* Features the link partner advertises */
>> __u32 reserved[2];
>> __u32 num_vfs; /* Enable SR-IOV VFs */
>> __u32 num_vmqs; /* Set number of queues for VMDq */
>> };
>>
>> If I understood it correctly, you are trying to set/unset spoofing on per
>> eth interface, which could be a PF on the hypervisor or a pci passthru-ed
>> VF in the linux guest. There are other security features that one could set
>> for a port on the VF (lets call it vport), e.g. setting a port VLAN ID for
>> a VF and specifying if the VF (VM) is allowed to send tagged/untagged
>> packets, setting a vport in port mirroring mode so that the PF can monitor
>> the traffic on a VF, setting a vport in promiscuous mode etc.
>>
>> Does it make sense to try to use ip link util to specify all these parameters,
>> since ip link already does the job of setting VF properties and VF port
>> profile?
>>
>> Any thoughts?
>>
>
> Sure, that's a possibility too. I was considering ethtool for this since MAC addresses and VLANs are fairly specific to Ethernet whereas netlink might apply to other types of physical networks. At least that's my understanding.
You could specify VF MAC and VLANs using netlink today.
e.g. ip link set ethX vf # mac, vlan etc.
Adding spoofing as follows would do it.
ip link set ethX vf # spoof on|off
Having SR-IOV features scattered among ethtool and ip link may be inconvenient for the end users.
CC-ing virtualization list.
>
> However, I have no strong feelings about it and if community consensus is to use ip link instead then that's fine by me.
>
> Of course, patches implementing such would be quite welcome also.
I could take a stab at it at the netlink side, if there is a consensus.
-Anirban
^ permalink raw reply
* [PATCH 1/2] bna: Remove Unnecessary CNA Check
From: Rasesh Mody @ 2011-07-28 21:49 UTC (permalink / raw)
To: davem, netdev; +Cc: adapter_linux_open_src_team, Rasesh Mody
Change details:
- ioc->cna is always set to 1 for eth functions, remove the check that
asserts IOC is in CNA mode in bfa_ioc_firmware_lock() and
bfa_ioc_firmware_unlock() in bfa_ioc_ct.c.
Signed-off-by: Rasesh Mody <rmody@brocade.com>
---
drivers/net/bna/bfa_ioc_ct.c | 12 ------------
1 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/drivers/net/bna/bfa_ioc_ct.c b/drivers/net/bna/bfa_ioc_ct.c
index 87aecdf..c43f942 100644
--- a/drivers/net/bna/bfa_ioc_ct.c
+++ b/drivers/net/bna/bfa_ioc_ct.c
@@ -84,12 +84,6 @@ bfa_ioc_ct_firmware_lock(struct bfa_ioc *ioc)
struct bfi_ioc_image_hdr fwhdr;
/**
- * Firmware match check is relevant only for CNA.
- */
- if (!ioc->cna)
- return true;
-
- /**
* If bios boot (flash based) -- do not increment usage count
*/
if (bfa_cb_image_get_size(BFA_IOC_FWIMG_TYPE(ioc)) <
@@ -140,12 +134,6 @@ bfa_ioc_ct_firmware_unlock(struct bfa_ioc *ioc)
u32 usecnt;
/**
- * Firmware lock is relevant only for CNA.
- */
- if (!ioc->cna)
- return;
-
- /**
* If bios boot (flash based) -- do not decrement usage count
*/
if (bfa_cb_image_get_size(BFA_IOC_FWIMG_TYPE(ioc)) <
--
1.7.1
^ permalink raw reply related
* [PATCH 2/2] bna: HW Interface Init Update
From: Rasesh Mody @ 2011-07-28 21:49 UTC (permalink / raw)
To: davem, netdev; +Cc: adapter_linux_open_src_team, Rasesh Mody
In-Reply-To: <1311889767-9848-1-git-send-email-rmody@brocade.com>
Change details:
- Split the hw interface into common and asic specific to support new asic
in the future.
- Fix bfa_ioc_ct_isr_mode_set() to also include the case that we are already
in the desired msix mode.
Signed-off-by: Rasesh Mody <rmody@brocade.com>
---
drivers/net/bna/bfa_ioc_ct.c | 28 +++++++++++++++++-----------
1 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/drivers/net/bna/bfa_ioc_ct.c b/drivers/net/bna/bfa_ioc_ct.c
index c43f942..29b5fd0 100644
--- a/drivers/net/bna/bfa_ioc_ct.c
+++ b/drivers/net/bna/bfa_ioc_ct.c
@@ -50,26 +50,32 @@ static enum bfa_status bfa_ioc_ct_pll_init(void __iomem *rb, bool fcmode);
static struct bfa_ioc_hwif nw_hwif_ct;
+static void
+bfa_ioc_set_ctx_hwif(struct bfa_ioc *ioc, struct bfa_ioc_hwif *hwif)
+{
+ hwif->ioc_firmware_lock = bfa_ioc_ct_firmware_lock;
+ hwif->ioc_firmware_unlock = bfa_ioc_ct_firmware_unlock;
+ hwif->ioc_notify_fail = bfa_ioc_ct_notify_fail;
+ hwif->ioc_ownership_reset = bfa_ioc_ct_ownership_reset;
+ hwif->ioc_sync_start = bfa_ioc_ct_sync_start;
+ hwif->ioc_sync_join = bfa_ioc_ct_sync_join;
+ hwif->ioc_sync_leave = bfa_ioc_ct_sync_leave;
+ hwif->ioc_sync_ack = bfa_ioc_ct_sync_ack;
+ hwif->ioc_sync_complete = bfa_ioc_ct_sync_complete;
+}
+
/**
* Called from bfa_ioc_attach() to map asic specific calls.
*/
void
bfa_nw_ioc_set_ct_hwif(struct bfa_ioc *ioc)
{
+ bfa_ioc_set_ctx_hwif(ioc, &nw_hwif_ct);
+
nw_hwif_ct.ioc_pll_init = bfa_ioc_ct_pll_init;
- nw_hwif_ct.ioc_firmware_lock = bfa_ioc_ct_firmware_lock;
- nw_hwif_ct.ioc_firmware_unlock = bfa_ioc_ct_firmware_unlock;
nw_hwif_ct.ioc_reg_init = bfa_ioc_ct_reg_init;
nw_hwif_ct.ioc_map_port = bfa_ioc_ct_map_port;
nw_hwif_ct.ioc_isr_mode_set = bfa_ioc_ct_isr_mode_set;
- nw_hwif_ct.ioc_notify_fail = bfa_ioc_ct_notify_fail;
- nw_hwif_ct.ioc_ownership_reset = bfa_ioc_ct_ownership_reset;
- nw_hwif_ct.ioc_sync_start = bfa_ioc_ct_sync_start;
- nw_hwif_ct.ioc_sync_join = bfa_ioc_ct_sync_join;
- nw_hwif_ct.ioc_sync_leave = bfa_ioc_ct_sync_leave;
- nw_hwif_ct.ioc_sync_ack = bfa_ioc_ct_sync_ack;
- nw_hwif_ct.ioc_sync_complete = bfa_ioc_ct_sync_complete;
-
ioc->ioc_hwif = &nw_hwif_ct;
}
@@ -297,7 +303,7 @@ bfa_ioc_ct_isr_mode_set(struct bfa_ioc *ioc, bool msix)
/**
* If already in desired mode, do not change anything
*/
- if (!msix && mode)
+ if ((!msix && mode) || (msix && !mode))
return;
if (msix)
--
1.7.1
^ permalink raw reply related
* RE: [RFC net-next PATCH 3/4] ethtool: Add new set commands
From: Rose, Gregory V @ 2011-07-28 21:34 UTC (permalink / raw)
To: Ben Hutchings
Cc: netdev@vger.kernel.org, davem@davemloft.net, Kirsher, Jeffrey T
In-Reply-To: <1311888004.2677.18.camel@deadeye>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Ben Hutchings
> Sent: Thursday, July 28, 2011 2:20 PM
> To: Rose, Gregory V
> Cc: netdev@vger.kernel.org; davem@davemloft.net; Kirsher, Jeffrey T
> Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
>
> On Wed, 2011-07-27 at 15:17 -0700, Greg Rose wrote:
> > Add new set commands to configure the number of SR-IOV VFs, the
> > number of VM queues and spoof checking on/off switch.
> >
> > Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> > ---
> >
> > include/linux/ethtool.h | 11 ++++++++++-
> > 1 files changed, 10 insertions(+), 1 deletions(-)
> >
> > diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> > index c6e427a..c4972ba 100644
> > --- a/include/linux/ethtool.h
> > +++ b/include/linux/ethtool.h
> > @@ -36,12 +36,14 @@ struct ethtool_cmd {
> > __u8 mdio_support;
> > __u32 maxtxpkt; /* Tx pkts before generating tx int */
> > __u32 maxrxpkt; /* Rx pkts before generating rx int */
> > + __u32 num_vfs; /* Enable SR-IOV VFs */
>
> What are the semantics of changing this after VFs have already been set
> up?
There's an example of it patch 4/4 in this set. The PF driver checks if any VFs are assigned and active and if not then it will disable and destroy all the current VFs via a call to pci_disable_sriov() and then call pci_enable_sriov() with the new number of VFs. Or, if the number of new VFs is zero then SR-IOV is left disabled on that PF.
Mostly this is to accommodate customer requests to be able to set a different number of VFs per PF or to only have specified PFs enable VFs. The current usage of the max_vfs module parameter is unwieldy in this sense as you must enable SR-IOV VFs on all physical functions found during the device probe with the same number of VFs.
>
> > + __u32 num_vmqs; /* Set number of queues for VMDq */
>
> VMDq is an Intel proprietary name. Please specify this in generic
> terms.
I'll use the more generic term VM queues.
>
> > __u16 speed_hi; /* The forced speed (upper
> > * bits) in Mbps. Please use
> > * ethtool_cmd_speed()/_set() to
> > * access it */
> > __u8 eth_tp_mdix;
> > - __u8 reserved2;
> > + __u8 spoof_check; /* Enable/Disable anti-spoofing */
> > __u32 lp_advertising; /* Features the link partner advertises */
> > __u32 reserved[2];
> > };
> > @@ -1121,6 +1123,13 @@ struct ethtool_ops {
> > #define AUTONEG_DISABLE 0x00
> > #define AUTONEG_ENABLE 0x01
> >
> > +/* Enable or disable MAC and/or VLAN spoofchecking.If this is
> > + * set to enable, then depending on the controller capabilities
> > + * MAC and/or VLAN spoofing will be turned on.
> > + */
> > +#define SPOOFCHECK_DISABLE 0x00
> > +#define SPOOFCHECK_ENABLE 0x01
>
> I'm not sure it's necessary to continue defining macros for booleans.
OK. I tend to just follow the conventions in the code I see when I'm not that familiar with it but in this case I'll just use true and false.
>
> This should not 'depend on controller capabilities'. If the
> administrator tries to enable this feature on a device that does not
> support it, the request must return an error rather than failing
> silently. (This is another reason to define new commands.)
Alright, I'll fix it up to work that way.
- Greg
^ permalink raw reply
* Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
From: Ben Hutchings @ 2011-07-28 21:20 UTC (permalink / raw)
To: Greg Rose; +Cc: netdev, davem, jeffrey.t.kirsher
In-Reply-To: <20110727221759.8435.11589.stgit@gitlad.jf.intel.com>
On Wed, 2011-07-27 at 15:17 -0700, Greg Rose wrote:
> Add new set commands to configure the number of SR-IOV VFs, the
> number of VM queues and spoof checking on/off switch.
>
> Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> ---
>
> include/linux/ethtool.h | 11 ++++++++++-
> 1 files changed, 10 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> index c6e427a..c4972ba 100644
> --- a/include/linux/ethtool.h
> +++ b/include/linux/ethtool.h
> @@ -36,12 +36,14 @@ struct ethtool_cmd {
> __u8 mdio_support;
> __u32 maxtxpkt; /* Tx pkts before generating tx int */
> __u32 maxrxpkt; /* Rx pkts before generating rx int */
> + __u32 num_vfs; /* Enable SR-IOV VFs */
What are the semantics of changing this after VFs have already been set
up?
> + __u32 num_vmqs; /* Set number of queues for VMDq */
VMDq is an Intel proprietary name. Please specify this in generic
terms.
> __u16 speed_hi; /* The forced speed (upper
> * bits) in Mbps. Please use
> * ethtool_cmd_speed()/_set() to
> * access it */
> __u8 eth_tp_mdix;
> - __u8 reserved2;
> + __u8 spoof_check; /* Enable/Disable anti-spoofing */
> __u32 lp_advertising; /* Features the link partner advertises */
> __u32 reserved[2];
> };
> @@ -1121,6 +1123,13 @@ struct ethtool_ops {
> #define AUTONEG_DISABLE 0x00
> #define AUTONEG_ENABLE 0x01
>
> +/* Enable or disable MAC and/or VLAN spoofchecking.If this is
> + * set to enable, then depending on the controller capabilities
> + * MAC and/or VLAN spoofing will be turned on.
> + */
> +#define SPOOFCHECK_DISABLE 0x00
> +#define SPOOFCHECK_ENABLE 0x01
I'm not sure it's necessary to continue defining macros for booleans.
This should not 'depend on controller capabilities'. If the
administrator tries to enable this feature on a device that does not
support it, the request must return an error rather than failing
silently. (This is another reason to define new commands.)
Ben.
> /* Mode MDI or MDI-X */
> #define ETH_TP_MDI_INVALID 0x00
> #define ETH_TP_MDI 0x01
>
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* RE: [RFC net-next PATCH 3/4] ethtool: Add new set commands
From: Rose, Gregory V @ 2011-07-28 21:16 UTC (permalink / raw)
To: Ben Hutchings, David Miller; +Cc: netdev@vger.kernel.org, Kirsher, Jeffrey T
In-Reply-To: <1311887685.2677.12.camel@deadeye>
> -----Original Message-----
> From: Ben Hutchings [mailto:bhutchings@solarflare.com]
> Sent: Thursday, July 28, 2011 2:15 PM
> To: David Miller
> Cc: Rose, Gregory V; netdev@vger.kernel.org; Kirsher, Jeffrey T
> Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
>
> On Thu, 2011-07-28 at 09:14 -0700, David Miller wrote:
> > From: "Rose, Gregory V" <gregory.v.rose@intel.com>
> > Date: Thu, 28 Jul 2011 08:51:05 -0700
> >
> > >> -----Original Message-----
> > >> From: David Miller [mailto:davem@davemloft.net]
> > >> Sent: Wednesday, July 27, 2011 10:28 PM
> > >> To: Rose, Gregory V
> > >> Cc: netdev@vger.kernel.org; bhutchings@solarflare.com; Kirsher,
> Jeffrey T
> > >> Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
> > >>
> > >> From: Greg Rose <gregory.v.rose@intel.com>
> > >> Date: Wed, 27 Jul 2011 15:17:59 -0700
> > >>
> > >> > Add new set commands to configure the number of SR-IOV VFs, the
> > >> > number of VM queues and spoof checking on/off switch.
> > >> >
> > >> > Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> > >> > ---
> > >> >
> > >> > include/linux/ethtool.h | 11 ++++++++++-
> > >> > 1 files changed, 10 insertions(+), 1 deletions(-)
> > >> >
> > >> > diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> > >> > index c6e427a..c4972ba 100644
> > >> > --- a/include/linux/ethtool.h
> > >> > +++ b/include/linux/ethtool.h
> > >> > @@ -36,12 +36,14 @@ struct ethtool_cmd {
> > >> > __u8 mdio_support;
> > >> > __u32 maxtxpkt; /* Tx pkts before generating tx int */
> > >> > __u32 maxrxpkt; /* Rx pkts before generating rx int */
> > >> > + __u32 num_vfs; /* Enable SR-IOV VFs */
> > >> > + __u32 num_vmqs; /* Set number of queues for VMDq */
> > >>
> > >> You can't change the layout of this datastructure in this way without
> > >> breaking every ethtool binary out there.
> > >>
> > >> You have to find another place to add these knobs.
> > >
> > > Perhaps at the end of the ethtool_cmd structure? Something like this:
> >
> > Either use the two reserved u32's we have there, or create a new
> > ethtool command and control structure.
>
> I'm going to insist on the latter. As I see it, struct ethtool_cmd is
> for Ethernet PHY settings. (The max{rx,tx}pkt fields weren't, but
> they're obsolete.)
OK, that's what I'll do.
- Greg
^ permalink raw reply
* Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
From: Ben Hutchings @ 2011-07-28 21:14 UTC (permalink / raw)
To: David Miller; +Cc: gregory.v.rose, netdev, jeffrey.t.kirsher
In-Reply-To: <20110728.091448.548423057039764289.davem@davemloft.net>
On Thu, 2011-07-28 at 09:14 -0700, David Miller wrote:
> From: "Rose, Gregory V" <gregory.v.rose@intel.com>
> Date: Thu, 28 Jul 2011 08:51:05 -0700
>
> >> -----Original Message-----
> >> From: David Miller [mailto:davem@davemloft.net]
> >> Sent: Wednesday, July 27, 2011 10:28 PM
> >> To: Rose, Gregory V
> >> Cc: netdev@vger.kernel.org; bhutchings@solarflare.com; Kirsher, Jeffrey T
> >> Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
> >>
> >> From: Greg Rose <gregory.v.rose@intel.com>
> >> Date: Wed, 27 Jul 2011 15:17:59 -0700
> >>
> >> > Add new set commands to configure the number of SR-IOV VFs, the
> >> > number of VM queues and spoof checking on/off switch.
> >> >
> >> > Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> >> > ---
> >> >
> >> > include/linux/ethtool.h | 11 ++++++++++-
> >> > 1 files changed, 10 insertions(+), 1 deletions(-)
> >> >
> >> > diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> >> > index c6e427a..c4972ba 100644
> >> > --- a/include/linux/ethtool.h
> >> > +++ b/include/linux/ethtool.h
> >> > @@ -36,12 +36,14 @@ struct ethtool_cmd {
> >> > __u8 mdio_support;
> >> > __u32 maxtxpkt; /* Tx pkts before generating tx int */
> >> > __u32 maxrxpkt; /* Rx pkts before generating rx int */
> >> > + __u32 num_vfs; /* Enable SR-IOV VFs */
> >> > + __u32 num_vmqs; /* Set number of queues for VMDq */
> >>
> >> You can't change the layout of this datastructure in this way without
> >> breaking every ethtool binary out there.
> >>
> >> You have to find another place to add these knobs.
> >
> > Perhaps at the end of the ethtool_cmd structure? Something like this:
>
> Either use the two reserved u32's we have there, or create a new
> ethtool command and control structure.
I'm going to insist on the latter. As I see it, struct ethtool_cmd is
for Ethernet PHY settings. (The max{rx,tx}pkt fields weren't, but
they're obsolete.)
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* "mlx4_en: Enabling new steering" brokenness
From: Roland Dreier @ 2011-07-28 21:04 UTC (permalink / raw)
To: Yevgeny Petrilin
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA
Hi Yevgeny!
So I have a system with an mlx4_en device with pretty old FW (version
2.7.700), old enough that the firmware doesn't have the capability
MLX4_DEV_CAP_FLAG_VEP_UC_STEER set. And it looks like mlx4_en is
completely broken in this case, at least since your commit
1679200f91da ("mlx4_en: Enabling new steering"). If I try to bring up
the interface, I just see:
mlx4_en: eth1: Failed to allocate RSS indirection QP
And this is failing because the QPN in 0.
The problem is in drivers/net/mlx4/port.c:mlx4_register_mac():
if (!(dev->caps.flags & MLX4_DEV_CAP_FLAG_VEP_UC_STEER))
*qpn = info->base_qpn + free;
but absolutely nothing ever initializes info->base_qpn. It looks like
the intention of the code is to initialize this in
mlx4_init_port_info(); however even the below hack doesn't seem to fix
things completely -- I still seem to have problems on the RX side
unless I enable promiscuous mode by running tcpdump:
diff --git a/drivers/net/mlx4/main.c b/drivers/net/mlx4/main.c
index c94b342..38092c7 100644
--- a/drivers/net/mlx4/main.c
+++ b/drivers/net/mlx4/main.c
@@ -1125,6 +1125,13 @@ static int mlx4_init_port_info(struct mlx4_dev *dev, int port)
info->port_attr.store = set_port_type;
sysfs_attr_init(&info->port_attr.attr);
+ err = mlx4_qp_reserve_range(dev, 1, 1, &info->base_qpn);
+ if (err) {
+ mlx4_err(dev, "Failed to reserve QP range for port %d\n", port);
+ info->port = -1;
+ return err;
+ }
+
err = device_create_file(&dev->pdev->dev, &info->port_attr);
if (err) {
mlx4_err(dev, "Failed to create file for port %d\n", port);
Could you take a look at getting this working? (Or update the driver
so it immediately fails with an informative message if you want to
rely on certain FW versions; and then strip out the old broken
compatibility code)
Thanks!
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: r8169 driver crashes in 2.6.32.43
From: Kasper Dupont @ 2011-07-28 21:01 UTC (permalink / raw)
To: Francois Romieu; +Cc: ivecera, hayeswang, gregkh, netdev
In-Reply-To: <20110728144719.GA11465@electric-eye.fr.zoreil.com>
On 28/07/11 16.47, Francois Romieu wrote:
> Kasper Dupont <kasperd@cpvhh.24.jul.2011.kasperd.net> :
> > On 28/07/11 14.45, Kasper Dupont wrote:
> > > On 28/07/11 14.23, Francois Romieu wrote:
> > > > You can replace them with plain printk(KERN_{INFO/ERR} "S: ...).
> > >
> > > Then it compiles, will let you know shortly how it works out.
> >
> > The last 24 lines before network stopped working:
> [...]
> > S: 000000c0
> > FEmp
> > S: 000000c0
> > FEmp
> > S: 00000040
> > S: 000000c4
> > S: 00000044
> > S: 00000040
>
> Can you revert the last patch and apply the one below ?
I tested it and put a picture of the output in the same place
as the error messages from before. If necessary I can try to
copy the dmesg output back over the other network interface
(assuming it is still up when the first one stops working).
>
> Network traffic capture at the remote end of the link would be welcome,
> especially ethernet MAC control frames.
I did a dump, but it showed nothing useful. The last packet
from the machine before the network stopped was a TCP ACK.
The sending machine send three more packets before it slowed
down, then send another three packets at lower speed and then
started sending arp requests, which were not answered.
There were three separate switches on the path between the
two machines. If necessary I can try to set up a network
with just a direct link between two hosts. I am not sure
which control frames you are referring to. Will tcpdump
capture them by default?
--
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,11,_+2,_+7,_+6);
^ permalink raw reply
* [patch 2/2] proc_fork_connector: a lockless ->real_parent usage is not safe
From: akpm @ 2011-07-28 20:54 UTC (permalink / raw)
To: davem; +Cc: netdev, akpm, oleg, johnpol, vzapolskiy, zbr
From: Oleg Nesterov <oleg@redhat.com>
proc_fork_connector() uses ->real_parent lockless. This is not safe if
copy_process() was called with CLONE_THREAD or CLONE_PARENT, in this case
the parent != current can go away at any moment.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Cc: Vladimir Zapolskiy <vzapolskiy@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Evgeniy Polyakov <zbr@ioremap.net>
Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/connector/cn_proc.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff -puN drivers/connector/cn_proc.c~proc_fork_connector-a-lockless-real_parent-usage-is-not-safe drivers/connector/cn_proc.c
--- a/drivers/connector/cn_proc.c~proc_fork_connector-a-lockless-real_parent-usage-is-not-safe
+++ a/drivers/connector/cn_proc.c
@@ -57,6 +57,7 @@ void proc_fork_connector(struct task_str
struct proc_event *ev;
__u8 buffer[CN_PROC_MSG_SIZE];
struct timespec ts;
+ struct task_struct *parent;
if (atomic_read(&proc_event_num_listeners) < 1)
return;
@@ -67,8 +68,11 @@ void proc_fork_connector(struct task_str
ktime_get_ts(&ts); /* get high res monotonic timestamp */
put_unaligned(timespec_to_ns(&ts), (__u64 *)&ev->timestamp_ns);
ev->what = PROC_EVENT_FORK;
- ev->event_data.fork.parent_pid = task->real_parent->pid;
- ev->event_data.fork.parent_tgid = task->real_parent->tgid;
+ rcu_read_lock();
+ parent = rcu_dereference(task->real_parent);
+ ev->event_data.fork.parent_pid = parent->pid;
+ ev->event_data.fork.parent_tgid = parent->tgid;
+ rcu_read_unlock();
ev->event_data.fork.child_pid = task->pid;
ev->event_data.fork.child_tgid = task->tgid;
_
^ permalink raw reply
* [patch 1/2] MAINTAINERS: orphan FrameRelay DLCI
From: akpm @ 2011-07-28 20:54 UTC (permalink / raw)
To: davem; +Cc: netdev, akpm, joe, shemminger
From: Joe Perches <joe@perches.com>
Mike McLagan hasn't contributed in many years and his email bounces.
Signed-off-by: Joe Perches <joe@perches.com>
Cc: David Miller <davem@davemloft.net>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
MAINTAINERS | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff -puN MAINTAINERS~maintainers-orphan-framerelay-dlci MAINTAINERS
--- a/MAINTAINERS~maintainers-orphan-framerelay-dlci
+++ a/MAINTAINERS
@@ -2643,9 +2643,8 @@ S: Maintained
F: arch/x86/math-emu/
FRAME RELAY DLCI/FRAD (Sangoma drivers too)
-M: Mike McLagan <mike.mclagan@linux.org>
L: netdev@vger.kernel.org
-S: Maintained
+S: Orphan
F: drivers/net/wan/dlci.c
F: drivers/net/wan/sdla.c
_
^ permalink raw reply
* [PATCH] xfrm: Fix key lengths for rfc3686(ctr(aes))
From: Tushar Gohad @ 2011-07-28 20:36 UTC (permalink / raw)
To: Joy Latten, Herbert Xu; +Cc: netdev, tgohad
Fix the min and max bit lengths for AES-CTR (RFC3686) keys.
The number of bits in key spec is the key length (128/256)
plus 32 bits of nonce.
This change takes care of the "Invalid key length" errors
reported by setkey when specifying 288 bit keys for aes-ctr.
Signed-off-by: Tushar Gohad <tgohad@mvista.com>
---
net/xfrm/xfrm_algo.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/xfrm/xfrm_algo.c b/net/xfrm/xfrm_algo.c
index 58064d9..791ab2e 100644
--- a/net/xfrm/xfrm_algo.c
+++ b/net/xfrm/xfrm_algo.c
@@ -462,8 +462,8 @@ static struct xfrm_algo_desc ealg_list[] = {
.desc = {
.sadb_alg_id = SADB_X_EALG_AESCTR,
.sadb_alg_ivlen = 8,
- .sadb_alg_minbits = 128,
- .sadb_alg_maxbits = 256
+ .sadb_alg_minbits = 160,
+ .sadb_alg_maxbits = 288
}
},
};
--
1.6.3.3.202.g91879
^ permalink raw reply related
* RE: [RFC net-next PATCH 3/4] ethtool: Add new set commands
From: Rose, Gregory V @ 2011-07-28 20:38 UTC (permalink / raw)
To: Anirban Chakraborty
Cc: David Miller, netdev, Ben Hutchings, Kirsher, Jeffrey T
In-Reply-To: <539DF151-E442-4375-8777-19676B95059B@qlogic.com>
> From: Anirban Chakraborty [mailto:anirban.chakraborty@qlogic.com]
> Sent: Thursday, July 28, 2011 12:04 PM
> To: Rose, Gregory V
> Cc: David Miller; netdev; Ben Hutchings; Kirsher, Jeffrey T
> Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
>
>
> On Jul 28, 2011, at 8:51 AM, Rose, Gregory V wrote:
>
>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Wednesday, July 27, 2011 10:28 PM
> To: Rose, Gregory V
> Cc: netdev@vger.kernel.org; bhutchings@solarflare.com; Kirsher, Jeffrey T
> Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
>
> From: Greg Rose <gregory.v.rose@intel.com>
> Date: Wed, 27 Jul 2011 15:17:59 -0700
>
> Add new set commands to configure the number of SR-IOV VFs, the
> number of VM queues and spoof checking on/off switch.
>
> Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> ---
>
> include/linux/ethtool.h | 11 ++++++++++-
> 1 files changed, 10 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> index c6e427a..c4972ba 100644
> --- a/include/linux/ethtool.h
> +++ b/include/linux/ethtool.h
> @@ -36,12 +36,14 @@ struct ethtool_cmd {
> __u8 mdio_support;
> __u32 maxtxpkt; /* Tx pkts before generating tx int */
> __u32 maxrxpkt; /* Rx pkts before generating rx int */
> + __u32 num_vfs; /* Enable SR-IOV VFs */
> + __u32 num_vmqs; /* Set number of queues for VMDq */
>
> You can't change the layout of this datastructure in this way without
> breaking every ethtool binary out there.
>
> You have to find another place to add these knobs.
>
> Perhaps at the end of the ethtool_cmd structure? Something like this:
>
> /* This should work for both 32 and 64 bit userland. */
> struct ethtool_cmd {
> __u32 cmd;
> __u32 supported; /* Features this interface supports */
> __u32 advertising; /* Features this interface advertises */
> __u16 speed; /* The forced speed (lower bits) in
> * Mbps. Please use
> * ethtool_cmd_speed()/_set() to
> * access it */
> __u8 duplex; /* Duplex, half or full */
> __u8 port; /* Which connector port */
> __u8 phy_address;
> __u8 transceiver; /* Which transceiver to use */
> __u8 autoneg; /* Enable or disable autonegotiation */
> __u8 mdio_support;
> __u32 maxtxpkt; /* Tx pkts before generating tx int */
> __u32 maxrxpkt; /* Rx pkts before generating rx int */
> __u16 speed_hi; /* The forced speed (upper
> * bits) in Mbps. Please use
> * ethtool_cmd_speed()/_set() to
> * access it */
> __u8 eth_tp_mdix;
> __u8 spoof_check; /* Enable/Disable anti-spoofing */
> __u32 lp_advertising; /* Features the link partner advertises */
> __u32 reserved[2];
> __u32 num_vfs; /* Enable SR-IOV VFs */
> __u32 num_vmqs; /* Set number of queues for VMDq */
> };
>
> If I understood it correctly, you are trying to set/unset spoofing on per
> eth interface, which could be a PF on the hypervisor or a pci passthru-ed
> VF in the linux guest. There are other security features that one could set
> for a port on the VF (lets call it vport), e.g. setting a port VLAN ID for
> a VF and specifying if the VF (VM) is allowed to send tagged/untagged
> packets, setting a vport in port mirroring mode so that the PF can monitor
> the traffic on a VF, setting a vport in promiscuous mode etc.
>
> Does it make sense to try to use ip link util to specify all these parameters,
> since ip link already does the job of setting VF properties and VF port
> profile?
>
> Any thoughts?
>
Sure, that's a possibility too. I was considering ethtool for this since MAC addresses and VLANs are fairly specific to Ethernet whereas netlink might apply to other types of physical networks. At least that's my understanding.
However, I have no strong feelings about it and if community consensus is to use ip link instead then that's fine by me.
Of course, patches implementing such would be quite welcome also.
;^)
- Greg
^ permalink raw reply
* Dead code in Starfire driver (set_vlan_mode())
From: Jesper Juhl @ 2011-07-28 20:35 UTC (permalink / raw)
To: linux-kernel
Cc: netdev, Alexey Dobriyan, Ben Hutchings, FUJITA Tomonori,
Akinobu Mita, David S. Miller, Ion Badulescu, becker
In drivers/net/starfire.c::set_vlan_mode() there is this code:
...
if (vlan_count == 32) {
ret |= PerfectFilterVlan;
while (vlan_count < 32) {
...
We've just tested 'vlan_count' as being equal to '32', so it's a bit silly
to follow that up with a loop that's conditioned on the variable being
less than that - it will never execute.
Now I don't know this code at all, so I have no idea what the proper fix
is (just remove the loop? change the loop condition? something else?), but
I do know that the current code makes little sense ;-)
Just for your information.
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply
* Re: special handling before ndo_start_xmit() been invoked
From: Jiri Pirko @ 2011-07-28 19:37 UTC (permalink / raw)
To: jiangtao.jit; +Cc: netdev
In-Reply-To: <201107271848349537853@gmail.com>
What would you want to achieve with that?
Wed, Jul 27, 2011 at 12:48:37PM CEST, jiangtao.jit@gmail.com wrote:
>Hi all:
>
>in struct net_device
>there is a function pointer rx_handler_func_t __rcu *rx_handler
>it's very convenient to register a function in an externel module
>and do some special handlings
>
>so i think what about to add an tx_handler_func
>before ndo_start_xmit() been invoked
>and do some special things before transmit
>
>is it necessary or there is already some other better methods to achieve this goal ?
>Thank you all
>
>-------
>2011-07-27
>jiangtao.jit
>
>--
>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 0/8] bna: Driver Fixes and Support for Re-architecture
From: Rasesh Mody @ 2011-07-28 19:30 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, Adapter Linux Open SRC Team
In-Reply-To: <20110727.223231.1088299143542685793.davem@davemloft.net>
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Wednesday, July 27, 2011 10:33 PM
>
>From: Rasesh Mody <rmody@brocade.com>
>Date: Tue, 26 Jul 2011 19:10:40 -0700
>
>> This patch-set consists of few fixes, HW reg consolidation and adds
>support
>> for re-architecture and re-organisation of the driver.
>
>Please do not mix bug fixes and feature changes.
>
>If you do this, I can't put the bug fixes into the current release.
>
>Seperate out the real pure bug fixes into a seperate series against
>the main 'net' GIT tree.
>
>Then you can submit your feature changes and cleanups seperately for
>'net-next'
We will submit the bug fixes and the feature changes separately.
Thanks,
Rasesh
^ permalink raw reply
* [PATCH] sunrpc: use better NUMA affinities
From: Eric Dumazet @ 2011-07-28 18:04 UTC (permalink / raw)
To: Trond Myklebust
Cc: J. Bruce Fields, Neil Brown, David Miller, linux-nfs, netdev,
linux-kernel
Use NUMA aware allocations to reduce latencies and increase throughput.
sunrpc kthreads can use kthread_create_on_node() if pool_mode is
"percpu" or "pernode", and svc_prepare_thread()/svc_init_buffer() can
also take into account NUMA node affinity for memory allocations.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: "J. Bruce Fields" <bfields@fieldses.org>
CC: Neil Brown <neilb@suse.de>
CC: David Miller <davem@davemloft.net>
---
fs/lockd/svc.c | 2 +-
fs/nfs/callback.c | 2 +-
include/linux/sunrpc/svc.h | 2 +-
net/sunrpc/svc.c | 33 ++++++++++++++++++++++++---------
4 files changed, 27 insertions(+), 12 deletions(-)
diff --git a/fs/lockd/svc.c b/fs/lockd/svc.c
index abfff9d..c061b9a 100644
--- a/fs/lockd/svc.c
+++ b/fs/lockd/svc.c
@@ -282,7 +282,7 @@ int lockd_up(void)
/*
* Create the kernel thread and wait for it to start.
*/
- nlmsvc_rqst = svc_prepare_thread(serv, &serv->sv_pools[0]);
+ nlmsvc_rqst = svc_prepare_thread(serv, &serv->sv_pools[0], NUMA_NO_NODE);
if (IS_ERR(nlmsvc_rqst)) {
error = PTR_ERR(nlmsvc_rqst);
nlmsvc_rqst = NULL;
diff --git a/fs/nfs/callback.c b/fs/nfs/callback.c
index e3d2942..ce620b5 100644
--- a/fs/nfs/callback.c
+++ b/fs/nfs/callback.c
@@ -125,7 +125,7 @@ nfs4_callback_up(struct svc_serv *serv)
else
goto out_err;
- return svc_prepare_thread(serv, &serv->sv_pools[0]);
+ return svc_prepare_thread(serv, &serv->sv_pools[0], NUMA_NO_NODE);
out_err:
if (ret == 0)
diff --git a/include/linux/sunrpc/svc.h b/include/linux/sunrpc/svc.h
index 223588a..a78a51e 100644
--- a/include/linux/sunrpc/svc.h
+++ b/include/linux/sunrpc/svc.h
@@ -404,7 +404,7 @@ struct svc_procedure {
struct svc_serv *svc_create(struct svc_program *, unsigned int,
void (*shutdown)(struct svc_serv *));
struct svc_rqst *svc_prepare_thread(struct svc_serv *serv,
- struct svc_pool *pool);
+ struct svc_pool *pool, int node);
void svc_exit_thread(struct svc_rqst *);
struct svc_serv * svc_create_pooled(struct svc_program *, unsigned int,
void (*shutdown)(struct svc_serv *),
diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
index 6a69a11..30d70ab 100644
--- a/net/sunrpc/svc.c
+++ b/net/sunrpc/svc.c
@@ -295,6 +295,18 @@ svc_pool_map_put(void)
}
+static int svc_pool_map_get_node(unsigned int pidx)
+{
+ const struct svc_pool_map *m = &svc_pool_map;
+
+ if (m->count) {
+ if (m->mode == SVC_POOL_PERCPU)
+ return cpu_to_node(m->pool_to[pidx]);
+ if (m->mode == SVC_POOL_PERNODE)
+ return m->pool_to[pidx];
+ }
+ return NUMA_NO_NODE;
+}
/*
* Set the given thread's cpus_allowed mask so that it
* will only run on cpus in the given pool.
@@ -499,7 +511,7 @@ EXPORT_SYMBOL_GPL(svc_destroy);
* We allocate pages and place them in rq_argpages.
*/
static int
-svc_init_buffer(struct svc_rqst *rqstp, unsigned int size)
+svc_init_buffer(struct svc_rqst *rqstp, unsigned int size, int node)
{
unsigned int pages, arghi;
@@ -513,7 +525,7 @@ svc_init_buffer(struct svc_rqst *rqstp, unsigned int size)
arghi = 0;
BUG_ON(pages > RPCSVC_MAXPAGES);
while (pages) {
- struct page *p = alloc_page(GFP_KERNEL);
+ struct page *p = alloc_pages_node(node, GFP_KERNEL, 0);
if (!p)
break;
rqstp->rq_pages[arghi++] = p;
@@ -536,11 +548,11 @@ svc_release_buffer(struct svc_rqst *rqstp)
}
struct svc_rqst *
-svc_prepare_thread(struct svc_serv *serv, struct svc_pool *pool)
+svc_prepare_thread(struct svc_serv *serv, struct svc_pool *pool, int node)
{
struct svc_rqst *rqstp;
- rqstp = kzalloc(sizeof(*rqstp), GFP_KERNEL);
+ rqstp = kzalloc_node(sizeof(*rqstp), GFP_KERNEL, node);
if (!rqstp)
goto out_enomem;
@@ -554,15 +566,15 @@ svc_prepare_thread(struct svc_serv *serv, struct svc_pool *pool)
rqstp->rq_server = serv;
rqstp->rq_pool = pool;
- rqstp->rq_argp = kmalloc(serv->sv_xdrsize, GFP_KERNEL);
+ rqstp->rq_argp = kmalloc_node(serv->sv_xdrsize, GFP_KERNEL, node);
if (!rqstp->rq_argp)
goto out_thread;
- rqstp->rq_resp = kmalloc(serv->sv_xdrsize, GFP_KERNEL);
+ rqstp->rq_resp = kmalloc_node(serv->sv_xdrsize, GFP_KERNEL, node);
if (!rqstp->rq_resp)
goto out_thread;
- if (!svc_init_buffer(rqstp, serv->sv_max_mesg))
+ if (!svc_init_buffer(rqstp, serv->sv_max_mesg, node))
goto out_thread;
return rqstp;
@@ -647,6 +659,7 @@ svc_set_num_threads(struct svc_serv *serv, struct svc_pool *pool, int nrservs)
struct svc_pool *chosen_pool;
int error = 0;
unsigned int state = serv->sv_nrthreads-1;
+ int node;
if (pool == NULL) {
/* The -1 assumes caller has done a svc_get() */
@@ -662,14 +675,16 @@ svc_set_num_threads(struct svc_serv *serv, struct svc_pool *pool, int nrservs)
nrservs--;
chosen_pool = choose_pool(serv, pool, &state);
- rqstp = svc_prepare_thread(serv, chosen_pool);
+ node = svc_pool_map_get_node(chosen_pool->sp_id);
+ rqstp = svc_prepare_thread(serv, chosen_pool, node);
if (IS_ERR(rqstp)) {
error = PTR_ERR(rqstp);
break;
}
__module_get(serv->sv_module);
- task = kthread_create(serv->sv_function, rqstp, serv->sv_name);
+ task = kthread_create_on_node(serv->sv_function, rqstp,
+ node, serv->sv_name);
if (IS_ERR(task)) {
error = PTR_ERR(task);
module_put(serv->sv_module);
^ permalink raw reply related
* [PATCH] net: fix new sunrpc kernel-doc warning
From: Randy Dunlap @ 2011-07-28 16:54 UTC (permalink / raw)
To: netdev; +Cc: davem
From: Randy Dunlap <rdunlap@xenotime.net>
Fix new kernel-doc warning in sunrpc:
Warning(net/sunrpc/xprt.c:196): No description found for parameter 'xprt'
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
---
net/sunrpc/xprt.c | 1 +
1 file changed, 1 insertion(+)
--- linux-3.0-git10.orig/net/sunrpc/xprt.c
+++ linux-3.0-git10/net/sunrpc/xprt.c
@@ -187,6 +187,7 @@ EXPORT_SYMBOL_GPL(xprt_load_transport);
/**
* xprt_reserve_xprt - serialize write access to transports
* @task: task that is requesting access to the transport
+ * @xprt: pointer to the target transport
*
* This prevents mixing the payload of separate requests, and prevents
* transport connects from colliding with writes. No congestion control
^ permalink raw reply
* RE: [RFC net-next PATCH 1/4] pci: Add flag indicating device has been assigned by KVM
From: Rose, Gregory V @ 2011-07-28 16:42 UTC (permalink / raw)
To: Ian Campbell
Cc: Konrad Rzeszutek Wilk, netdev@vger.kernel.org,
davem@davemloft.net, bhutchings@solarflare.com,
Kirsher, Jeffrey T, Jesse Barnes, linux-pci@vger.kernel.org
In-Reply-To: <1311870459.24408.151.camel@cthulhu.hellion.org.uk>
> -----Original Message-----
> From: Ian Campbell [mailto:ijc@hellion.org.uk]
> Sent: Thursday, July 28, 2011 9:28 AM
> To: Rose, Gregory V
> Cc: Konrad Rzeszutek Wilk; netdev@vger.kernel.org; davem@davemloft.net;
> bhutchings@solarflare.com; Kirsher, Jeffrey T; Jesse Barnes; linux-
> pci@vger.kernel.org
> Subject: RE: [RFC net-next PATCH 1/4] pci: Add flag indicating device has
> been assigned by KVM
>
> On Thu, 2011-07-28 at 08:58 -0700, Rose, Gregory V wrote:
> > > -----Original Message-----
> > > From: Ian Campbell [mailto:ijc@hellion.org.uk]
> > > Sent: Thursday, July 28, 2011 8:11 AM
> > > To: Rose, Gregory V; Konrad Rzeszutek Wilk
> > > Cc: netdev@vger.kernel.org; davem@davemloft.net;
> > > bhutchings@solarflare.com; Kirsher, Jeffrey T; Jesse Barnes; linux-
> > > pci@vger.kernel.org
> > > Subject: Re: [RFC net-next PATCH 1/4] pci: Add flag indicating device
> has
> > > been assigned by KVM
> > >
> > > On Wed, 2011-07-27 at 15:17 -0700, Greg Rose wrote:
> > > > Device drivers that create and destroy SR-IOV virtual functions via
> > > > calls to pci_enable_sriov() and pci_disable_sriov can cause
> catastrophic
> > > > failures if they attempt to destroy VFs while they are assigned to
> > > > guest virtual machines. By adding a flag for use by the KVM module
> > > > to indicate that a device is assigned a device driver can check that
> > > > flag and avoid destroying VFs while they are assigned and avoid
> system
> > > > failures.
> > > >
> > > > Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> > > > ---
> > > >
> > > > include/linux/pci.h | 2 ++
> > >
> > > I added Jesse and linux-pci to CC.
> > >
> > > > virt/kvm/assigned-dev.c | 2 ++
> > > > virt/kvm/iommu.c | 4 ++++
> > > > 3 files changed, 8 insertions(+), 0 deletions(-)
> > >
> > > I suppose this would also be useful in Xen's pciback or any other
> system
> > > which does passthrough? (Konrad CC'd for pciback)
> >
> > Definitely yes. Xen experiences the same issues when the PF driver is
> > removed while VFs are assigned to guests.
> >
> > >
> > > Is there some common lower layer we could hook this in to? (does
> > > iommu_attach/detach_device make sense?) Or shall we just add the flag
> > > manipulations to pciback as well?
> > [Greg Rose]
> >
> > I was unaware of any common lower layers, i.e I didn't know that Xen
> > also uses the iommu_attach/detach_device calls.
>
> my mistake -- under Xen the iommu is driver by the hypervisor and not
> the domain 0 kernel so there is no iommu_* in pciback.
>
> > It took me a week of digging around in the KVM module code just to
> > find these hooks.
>
> I'm not actually sure where in pciback the right place to put this would
> be is, perhaps Konrad has an idea.
OK, but I hope Xen can still use the dev_flag assignment bit.
Thanks,
- Greg
^ permalink raw reply
* Re: strange behaviour of MC7700 with sierra_net
From: Phil Sutter @ 2011-07-28 16:32 UTC (permalink / raw)
To: Dan Williams
Cc: Elina Pasheva, dbrownell-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Rory Filer
In-Reply-To: <1311795643.17655.13.camel-wKZy7rqYPVb5EHUCmHmTqw@public.gmane.org>
Dan,
Thanks for the quick reply!
On Wed, Jul 27, 2011 at 02:40:40PM -0500, Dan Williams wrote:
> I wonder if the firmware changed and Sierra hasn't updated the driver
> yet. I've got a usb306 which also uses sierra_net which doesn't have
> this problem. It looks like the driver tries to sync with the firmware
> right after binding to the net interface, so that means at least a
> couple of SYNC requests have already happened by the time you start
> getting errors. My first thought here is simply that the firmware on
> the MC7700 doesn't work like the rest of the devices that sierra_net
> expects, and for that you'd have to get Sierra to weigh in on the
> required changes :(
That's exactly the case. My printf-debugging shows that ~30 calls to
sierra_net_dosync() sycceed before it starts failing. Why the heck does
that work if I set the interface up? When doing so, the driver
immediately receives a whole bunch of restart-messages. Looks
like the number matches the number of successfully sent sync-messages.
This looks like the turned down interface is holding something back, but
looking with usbmon I see communication (this is the point when the
sync-messages start to fail):
| da9ebc40 74.842086 S Co:1:035:0 s 21 00 0000 0007 0004 4 = 00002000
| da9ebc40 74.842971 C Co:1:035:0 0 4 >
| da9ebc40 76.848151 S Co:1:035:0 s 21 00 0000 0007 0004 4 = 00002000
| da9ebc40 76.848835 C Co:1:035:0 -32 4 >
But maybe something should be done in the beginning that's done when the
interface comes up. The capture in that situation is this:
| da9ebc40 88.898257 S Co:1:035:0 s 21 00 0000 0007 0004 4 = 00002000
| da9ebc40 88.898860 C Co:1:035:0 -32 4 >
| dbe29dc0 90.548212 S Ii:1:035:8 -:64 64 <
| da9ebc40 90.548619 S Bi:1:035:9 - 8192 <
| dbe29c40 90.548632 S Bi:1:035:9 - 8192 <
| daab45c0 90.548639 S Bi:1:035:9 - 8192 <
| daac3640 90.548645 S Bi:1:035:9 - 8192 <
| da9cce40 90.548651 S Bi:1:035:9 - 8192 <
| dbe6b7c0 90.548657 S Bi:1:035:9 - 8192 <
| dab0ae40 90.548663 S Bi:1:035:9 - 8192 <
| dbe29640 90.548669 S Bi:1:035:9 - 8192 <
| dbe29340 90.548675 S Bi:1:035:9 - 8192 <
| dbe6b540 90.548681 S Bi:1:035:9 - 8192 <
| dbe6b0c0 90.548688 S Bi:1:035:9 - 8192 <
| dbe29dc0 90.550814 C Ii:1:035:8 0:64 8 = a1010000 07000000
| dbe29dc0 90.550868 S Ii:1:035:8 -:64 64 <
| daac3540 90.550980 S Ci:1:035:0 s a1 01 0000 0007 0400 1024 <
| daac3540 90.551694 C Ci:1:035:0 0 68 = 00406200 53574939 32303058 5f30332e 30302e30 322e3030 41502052 32303332
| dbe29dc0 90.558801 C Ii:1:035:8 0:64 8 = a1010000 07000000
| dbe29dc0 90.558960 S Ii:1:035:8 -:64 64 <
| daac3540 90.559054 S Ci:1:035:0 s a1 01 0000 0007 0400 1024 <
| daac3540 90.559544 C Ci:1:035:0 0 68 = 00406200 53574939 32303058 5f30332e 30302e30 322e3030 41502052 32303332
| dbe29dc0 90.566798 C Ii:1:035:8 0:64 8 = a1010000 07000000
The kernel log output of the above timeframe:
| Jul 28 17:55:36 (none) user.debug kernel: [266833.170570] usb 1-1: sierra_net_send_sync
| Jul 28 17:55:36 (none) user.info kernel: [266833.170590] sierra_net_send_sync: netif is not running
| Jul 28 17:55:36 (none) user.err kernel: [266833.171515] sierra_net 1-1:1.7: wwan0: Submit SYNC failed -32
| Jul 28 17:55:36 (none) user.err kernel: [266833.174713] sierra_net 1-1:1.7: wwan0: Send SYNC failed, status -32
| Jul 28 17:55:38 (none) user.debug kernel: [266834.823421] usb 1-1: sierra_net_status
| Jul 28 17:55:38 (none) user.debug kernel: [266834.824316] usb 1-1: sierra_net_kevent: Received status message, 0044 bytes
| Jul 28 17:55:38 (none) user.debug kernel: [266834.824475] usb 1-1: Restart reported: 0, stopping sync timer
| Jul 28 17:55:38 (none) user.debug kernel: [266834.831400] usb 1-1: sierra_net_status
| Jul 28 17:55:38 (none) user.debug kernel: [266834.832268] usb 1-1: sierra_net_kevent: Received status message, 0044 bytes
| Jul 28 17:55:38 (none) user.debug kernel: [266834.832426] usb 1-1: Restart reported: 0, stopping sync timer
> Since the MC7700 is an LTE module it's 100% likely the firmware is
> different, or at least significantly rebased, from the existing Sierra
> HSPA/EVDO parts that use sierra_net and thus I wouldn't necessarily
> expect it to work out of the box.
Well, it's obviously not that bad. Setting wwan0 up as a workaround,
everything's quite fine. Also, if I'm fast enough initialising the modem
via AT-commands before the control-tty dies, I can dial in even with
wwan0 being down, set it up and receive an address via DHCP.
Since the MC7700 has the same USB product and vendor IDs as any other
direct-IP device (1199:68a3), Sierra may indeed have meant this device
to act identical to the other ones. Or their driver-developers are just
a little bit masochistic. ;)
Hopefully Elina Pasheva can provide some helpful insights here.
Greetings, Phil
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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