* Re: [PATCH] e1000: remove unused variables
From: Hisashi T Fujinaka @ 2014-11-27 5:59 UTC (permalink / raw)
To: Sudip Mukherjee
Cc: Jeff Kirsher, Jesse Brandeburg, Bruce Allan, Carolyn Wyborny,
Don Skidmore, Greg Rose, Matthew Vick, John Ronciak,
Mitch Williams, Linux NICS, e1000-devel, netdev, linux-kernel
In-Reply-To: <1417065728-5592-1-git-send-email-sudipm.mukherjee@gmail.com>
I'm pretty sure those double reads are there for a reason, so most of
this I'm going to have to check on Monday. We have a long holiday
weekend here in the US.
I'm not sure why you're bothering with an old driver like this, but if
you haven't actually tried this on all the hardware it pertains to, I'm
going want to NAK this.
I should do this from my todd.fujinaka@intel.com account but it's 10PM
on the first day of a long holiday weekend.
On Thu, 27 Nov 2014, Sudip Mukherjee wrote:
> these variables were only being assigned some values, but were never
> used.
>
> Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
> ---
> drivers/net/ethernet/intel/e1000/e1000_hw.c | 142 ++++++++++++--------------
> drivers/net/ethernet/intel/e1000/e1000_main.c | 3 -
> 2 files changed, 66 insertions(+), 79 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/e1000/e1000_hw.c b/drivers/net/ethernet/intel/e1000/e1000_hw.c
> index 45c8c864..7812f59 100644
> --- a/drivers/net/ethernet/intel/e1000/e1000_hw.c
> +++ b/drivers/net/ethernet/intel/e1000/e1000_hw.c
> @@ -154,7 +154,6 @@ static s32 e1000_set_phy_type(struct e1000_hw *hw)
> */
> static void e1000_phy_init_script(struct e1000_hw *hw)
> {
> - u32 ret_val;
> u16 phy_saved_data;
>
> if (hw->phy_init_script) {
> @@ -163,7 +162,7 @@ static void e1000_phy_init_script(struct e1000_hw *hw)
> /* Save off the current value of register 0x2F5B to be restored
> * at the end of this routine.
> */
> - ret_val = e1000_read_phy_reg(hw, 0x2F5B, &phy_saved_data);
> + e1000_read_phy_reg(hw, 0x2F5B, &phy_saved_data);
>
> /* Disabled the PHY transmitter */
> e1000_write_phy_reg(hw, 0x2F5B, 0x0003);
> @@ -402,7 +401,6 @@ s32 e1000_reset_hw(struct e1000_hw *hw)
> {
> u32 ctrl;
> u32 ctrl_ext;
> - u32 icr;
> u32 manc;
> u32 led_ctrl;
> s32 ret_val;
> @@ -527,7 +525,7 @@ s32 e1000_reset_hw(struct e1000_hw *hw)
> ew32(IMC, 0xffffffff);
>
> /* Clear any pending interrupt events. */
> - icr = er32(ICR);
> + er32(ICR);
>
> /* If MWI was previously enabled, reenable it. */
> if (hw->mac_type == e1000_82542_rev2_0) {
> @@ -2396,16 +2394,13 @@ static s32 e1000_check_for_serdes_link_generic(struct e1000_hw *hw)
> */
> s32 e1000_check_for_link(struct e1000_hw *hw)
> {
> - u32 rxcw = 0;
> - u32 ctrl;
> u32 status;
> u32 rctl;
> u32 icr;
> - u32 signal = 0;
> s32 ret_val;
> u16 phy_data;
>
> - ctrl = er32(CTRL);
> + er32(CTRL);
> status = er32(STATUS);
>
> /* On adapters with a MAC newer than 82544, SW Definable pin 1 will be
> @@ -2414,12 +2409,9 @@ s32 e1000_check_for_link(struct e1000_hw *hw)
> */
> if ((hw->media_type == e1000_media_type_fiber) ||
> (hw->media_type == e1000_media_type_internal_serdes)) {
> - rxcw = er32(RXCW);
> + er32(RXCW);
>
> if (hw->media_type == e1000_media_type_fiber) {
> - signal =
> - (hw->mac_type >
> - e1000_82544) ? E1000_CTRL_SWDPIN1 : 0;
> if (status & E1000_STATUS_LU)
> hw->get_link_status = false;
> }
> @@ -4698,78 +4690,76 @@ s32 e1000_led_off(struct e1000_hw *hw)
> */
> static void e1000_clear_hw_cntrs(struct e1000_hw *hw)
> {
> - volatile u32 temp;
> -
> - temp = er32(CRCERRS);
> - temp = er32(SYMERRS);
> - temp = er32(MPC);
> - temp = er32(SCC);
> - temp = er32(ECOL);
> - temp = er32(MCC);
> - temp = er32(LATECOL);
> - temp = er32(COLC);
> - temp = er32(DC);
> - temp = er32(SEC);
> - temp = er32(RLEC);
> - temp = er32(XONRXC);
> - temp = er32(XONTXC);
> - temp = er32(XOFFRXC);
> - temp = er32(XOFFTXC);
> - temp = er32(FCRUC);
> -
> - temp = er32(PRC64);
> - temp = er32(PRC127);
> - temp = er32(PRC255);
> - temp = er32(PRC511);
> - temp = er32(PRC1023);
> - temp = er32(PRC1522);
> -
> - temp = er32(GPRC);
> - temp = er32(BPRC);
> - temp = er32(MPRC);
> - temp = er32(GPTC);
> - temp = er32(GORCL);
> - temp = er32(GORCH);
> - temp = er32(GOTCL);
> - temp = er32(GOTCH);
> - temp = er32(RNBC);
> - temp = er32(RUC);
> - temp = er32(RFC);
> - temp = er32(ROC);
> - temp = er32(RJC);
> - temp = er32(TORL);
> - temp = er32(TORH);
> - temp = er32(TOTL);
> - temp = er32(TOTH);
> - temp = er32(TPR);
> - temp = er32(TPT);
> -
> - temp = er32(PTC64);
> - temp = er32(PTC127);
> - temp = er32(PTC255);
> - temp = er32(PTC511);
> - temp = er32(PTC1023);
> - temp = er32(PTC1522);
> -
> - temp = er32(MPTC);
> - temp = er32(BPTC);
> + er32(CRCERRS);
> + er32(SYMERRS);
> + er32(MPC);
> + er32(SCC);
> + er32(ECOL);
> + er32(MCC);
> + er32(LATECOL);
> + er32(COLC);
> + er32(DC);
> + er32(SEC);
> + er32(RLEC);
> + er32(XONRXC);
> + er32(XONTXC);
> + er32(XOFFRXC);
> + er32(XOFFTXC);
> + er32(FCRUC);
> +
> + er32(PRC64);
> + er32(PRC127);
> + er32(PRC255);
> + er32(PRC511);
> + er32(PRC1023);
> + er32(PRC1522);
> +
> + er32(GPRC);
> + er32(BPRC);
> + er32(MPRC);
> + er32(GPTC);
> + er32(GORCL);
> + er32(GORCH);
> + er32(GOTCL);
> + er32(GOTCH);
> + er32(RNBC);
> + er32(RUC);
> + er32(RFC);
> + er32(ROC);
> + er32(RJC);
> + er32(TORL);
> + er32(TORH);
> + er32(TOTL);
> + er32(TOTH);
> + er32(TPR);
> + er32(TPT);
> +
> + er32(PTC64);
> + er32(PTC127);
> + er32(PTC255);
> + er32(PTC511);
> + er32(PTC1023);
> + er32(PTC1522);
> +
> + er32(MPTC);
> + er32(BPTC);
>
> if (hw->mac_type < e1000_82543)
> return;
>
> - temp = er32(ALGNERRC);
> - temp = er32(RXERRC);
> - temp = er32(TNCRS);
> - temp = er32(CEXTERR);
> - temp = er32(TSCTC);
> - temp = er32(TSCTFC);
> + er32(ALGNERRC);
> + er32(RXERRC);
> + er32(TNCRS);
> + er32(CEXTERR);
> + er32(TSCTC);
> + er32(TSCTFC);
>
> if (hw->mac_type <= e1000_82544)
> return;
>
> - temp = er32(MGTPRC);
> - temp = er32(MGTPDC);
> - temp = er32(MGTPTC);
> + er32(MGTPRC);
> + er32(MGTPDC);
> + er32(MGTPTC);
> }
>
> /**
> diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c
> index 24f3986..a70ea46 100644
> --- a/drivers/net/ethernet/intel/e1000/e1000_main.c
> +++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
> @@ -2443,7 +2443,6 @@ static void e1000_watchdog(struct work_struct *work)
> if (link) {
> if (!netif_carrier_ok(netdev)) {
> u32 ctrl;
> - bool txb2b = true;
> /* update snapshot of PHY registers on LSC */
> e1000_get_speed_and_duplex(hw,
> &adapter->link_speed,
> @@ -2465,11 +2464,9 @@ static void e1000_watchdog(struct work_struct *work)
> adapter->tx_timeout_factor = 1;
> switch (adapter->link_speed) {
> case SPEED_10:
> - txb2b = false;
> adapter->tx_timeout_factor = 16;
> break;
> case SPEED_100:
> - txb2b = false;
> /* maybe add some timeout factor ? */
> break;
> }
>
--
Hisashi T Fujinaka - htodd@twofifty.com
BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee
^ permalink raw reply
* Re: [patch net-next v2 05/10] rocker: introduce rocker switch driver
From: Florian Fainelli @ 2014-11-27 14:09 UTC (permalink / raw)
To: Jiri Pirko, Thomas Graf
Cc: John Fastabend, netdev, davem, nhorman, andy, dborkman, ogerlitz,
jesse, pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, jhs, sfeldma, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcr
In-Reply-To: <20141111154017.GH1825@nanopsycho.lan>
Le 11/11/2014 07:40, Jiri Pirko a écrit :
> Tue, Nov 11, 2014 at 04:32:32PM CET, tgraf@suug.ch wrote:
>> On 11/11/14 at 04:19pm, Jiri Pirko wrote:
>>> Tue, Nov 11, 2014 at 03:29:46PM CET, tgraf@suug.ch wrote:
>>>> On 11/10/14 at 02:04pm, John Fastabend wrote:
>>>>> On 11/09/2014 02:51 AM, Jiri Pirko wrote:
>>>>>> +static int rocker_port_sw_parent_id_get(struct net_device *dev,
>>>>>> + struct netdev_phys_item_id *psid)
>>>>>> +{
>>>>>> + struct rocker_port *rocker_port = netdev_priv(dev);
>>>>>> + struct rocker *rocker = rocker_port->rocker;
>>>>>> +
>>>>>
>>>>> hmm looks like you read this out of a magic switch register :) but
>>>>> my switch doesn't have this magic reg. I suposse the switch MAC address
>>>>> should work.
>>>>
>>>> This needs more work afterwards. Either we define that the switch ID
>>>> is only unique in combination with the parent ifindex or we need to
>>>> introduce a notation of uniquness into the switch ID itself.
>>>
>>> This is something similar to physical port id. Each driver should take
>>> care of generating that id.
>>
>> If the ID is only unique within a driver, then the user space cannot
>> rely on using the ID to group switch ports. Multiple drivers might
>> come up with the same ID.
>
> Well, as I said, it is the same as for physical port id. But if needed,
> there can be added some simple mechanism for the id registration
> ensuring their uniqueness.
We could use the idr/ida subsystem to provide a global unique id per
switch device that gets registered, ultimately, I suspect that a
management application might want to get some sense of the topology by
exploiting some unique HW properties such as:
- MDIO bus address for MDIO-connected switches
- SPI chip-select address
- GPIO(s) used to connect
- PCI bus/slot
they are also unique by design, and add to that any revision/OUI
register that is available for the driver. I can't find of a good way to
hash that to produce a unique identifier, but maybe we can use that
information somehow.
>
>>
>> Even now, multiple rocker instances would have the same ID.
>
> It depends on what hw returns to driver.
>
^ permalink raw reply
* [PATCH net-next V3] tun/macvtap: use consume_skb() instead of kfree_skb() when needed
From: Jason Wang @ 2014-11-27 6:36 UTC (permalink / raw)
To: davem, netdev, linux-kernel; +Cc: mst, Jason Wang, Eric Dumazet
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>
---
Changes from V2:
- use unlikely() when necessary
Changes from V1:
- check the return value of tun/macvtap_put_user()
---
drivers/net/macvtap.c | 5 ++++-
drivers/net/tun.c | 5 ++++-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 42a80d3..86f6bf8 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -862,7 +862,10 @@ static ssize_t macvtap_do_read(struct macvtap_queue *q,
}
iov_iter_init(&iter, READ, iv, segs, len);
ret = macvtap_put_user(q, skb, &iter);
- kfree_skb(skb);
+ if (unlikely(ret < 0))
+ kfree_skb(skb);
+ else
+ consume_skb(skb);
break;
}
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index ac53a73..82a9bf0 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1363,7 +1363,10 @@ static ssize_t tun_do_read(struct tun_struct *tun, struct tun_file *tfile,
iov_iter_init(&iter, READ, iv, segs, len);
ret = tun_put_user(tun, tfile, skb, &iter);
- kfree_skb(skb);
+ if (unlikely(ret < 0))
+ kfree_skb(skb);
+ else
+ consume_skb(skb);
return ret;
}
--
1.9.1
^ permalink raw reply related
* [PATCH net-next] vhost: remove unnecessary forward declarations in vhost.h
From: Jason Wang @ 2014-11-27 6:41 UTC (permalink / raw)
To: mst, virtualization, netdev, linux-kernel; +Cc: kvm
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/vhost/vhost.h | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index 3eda654..7d039ef 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -12,8 +12,6 @@
#include <linux/virtio_ring.h>
#include <linux/atomic.h>
-struct vhost_device;
-
struct vhost_work;
typedef void (*vhost_work_fn_t)(struct vhost_work *work);
@@ -54,8 +52,6 @@ struct vhost_log {
u64 len;
};
-struct vhost_virtqueue;
-
/* The virtqueue structure describes a queue attached to a device. */
struct vhost_virtqueue {
struct vhost_dev *dev;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH V1 net-next 1/2] pgtable: Add API to query if write combining is available
From: Or Gerlitz @ 2014-11-27 6:48 UTC (permalink / raw)
To: Moshe Lazer
Cc: David Miller, Or Gerlitz, Jack Morgenstein, talal@mellanox.com,
Yevgeny Petrilin, Linux Netdev List, Amir Vadai, moshel
In-Reply-To: <543A4FE4.7010807@dev.mellanox.co.il>
On Sun, Oct 12, 2014 at 11:54 AM, Moshe Lazer <moshel@dev.mellanox.co.il> wrote:
>
> On 10/8/2014 7:24 PM, David Miller wrote:
>>
>> From: Moshe Lazer <moshel@dev.mellanox.co.il>
>> Date: Wed, 08 Oct 2014 11:44:57 +0300
>>
>>>> #if defined(__i386__) || defined(__x86_64__)
>>>> if (map->type == _DRM_REGISTERS && !(map->flags &
>>>> _DRM_WRITE_COMBINING))
>>>> tmp = pgprot_noncached(tmp);
>>>> else
>>>> tmp = pgprot_writecombine(tmp);
>>>> #elif defined(__powerpc__)
>>>> pgprot_val(tmp) |= _PAGE_NO_CACHE;
>>>> if (map->type == _DRM_REGISTERS)
>>>> pgprot_val(tmp) |= _PAGE_GUARDED;
>>>> #elif defined(__ia64__)
>>>> if (efi_range_is_wc(vma->vm_start, vma->vm_end -
>>>> vma->vm_start))
>>>> tmp = pgprot_writecombine(tmp);
>>>> else
>>>> tmp = pgprot_noncached(tmp);
>>>> #elif defined(__sparc__) || defined(__arm__) || defined(__mips__)
>>>> tmp = pgprot_noncached(tmp);
>>>> #endif
>>>
>>> The idea was to provide an indication as for whether the arch supports
>>> write-combining in general.
>>> If we want to benefit from blue flame operations, we need to map the
>>> blue flame registers as write combining - otherwise there is no
>>> benefit. So we would like to know if write combining is supported by
>>> the system or not.
>>>
>> You completely miss my point. On a given architectuire it might be
>> _illegal_ to map certain address ranges as write-combining without
>> checks like the ones above that ia64 needs.
>>
>> Therefore your proposed interface is by definition insufficient.
>
> Thanks David, I'll try to clarify my point.
> For me the writecombine_available() is a way to know if the
> pgprot_writecombine() is effective or just cover call to the
> pgprot_noncached().
> I want to use the writecombine_available() regardless to the mapping
> address.
> For example in mlx4 query_device I want to indicate that blue-flame is not
> supported if `writecombine_available() == false`.
> In this case we don't have the mapping address yet.
>
> Later on if an arch has write-combining (writecombine_available() == true)
> when we try to map the blue-flame registers (in mlx4_ib_mmap):
>
> vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
>
> if (io_remap_pfn_range(vma, vma->vm_start,
> to_mucontext(context)->uar.pfn +
> dev->dev->caps.num_uars,
> PAGE_SIZE, vma->vm_page_prot))
> return -EAGAIN;
>
> I can be sure that pgprot_writecombine() is not a cover for
> pgprot_noncached().
> The address checks that you mentioned should be part of io_remap_pfn_range,
> this function should fail if the vma->vm_start is not compatible to the
> vma->vm_page_prot.
> Please let me know if I misunderstood something.
Hi Dave,
Pinging you... could you respond on Moshe's email which hopefully
addresses your comments?
Or.
^ permalink raw reply
* Re: [patch net-next v3 02/17] net: make vid as a parameter for ndo_fdb_add/ndo_fdb_del
From: Scott Feldman @ 2014-11-27 6:50 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: John Fastabend, Jiri Pirko, Netdev, David S. Miller,
nhorman@tuxdriver.com, Andy Gospodarek, Thomas Graf,
dborkman@redhat.com, ogerlitz@mellanox.com, jesse@nicira.com,
pshelar@nicira.com, azhou@nicira.com, ben@decadent.org.uk,
stephen@networkplumber.org, Kirsher, Jeffrey T,
vyasevic@redhat.com, Cong Wang, Eric Dumazet, Florian Fainelli,
Roopa Prabhu, John Linville
In-Reply-To: <5475B952.2080500@mojatatu.com>
On Wed, Nov 26, 2014 at 1:28 AM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> On 11/25/14 22:59, Scott Feldman wrote:
>>
>> On Tue, Nov 25, 2014 at 5:19 PM, Jamal Hadi Salim <jhs@mojatatu.com>
>> wrote:
>>>
>>> On 11/25/14 21:36, Scott Feldman wrote:
>
>
>>>
>>>>> Ok, guess i am gonna have to go stare at the code some more.
>>>>> I thought we returned one of the error codes?
>>>>> A bitmask would work for a single entry - because you have two
>>>>> options add to h/ware and/or s/ware. So response is easy to encode.
>>>>> But if i have 1000 and they are sparsely populated (think an indexed
>>>>> table and i have indices 1, 23, 45, etc), then a bitmask would be
>>>>> hard to use.
>>>>
>>>>
>>>>
>>>> I'm confused by this discussion.
>>>
>>>
>>>
>>> This is about the policy which states "install as many as you can, dont
>>> worry about failures". In such a case, how do you tell user space back
>>> "oh, btw you know your request #1, #23, and 45 went ok, but nothing else
>>> worked". A simple return code wont work. You could return a code to
>>> say "some worked". At which case user space could dump and find out only
>>> #1, #23 and #45 worked.
>>
>>
>> You request for what? That's my confusion.
>
>
> Scott, you are gonna make do this all over again?;->
> The summary is there are three possible policies that could be
> identified by the user asking for a kernel operation.
> One use case example was to send a bunch of (for example)
> create/updates and request that the kernel should not abort on a
> failure of a single one but to keep going and create/update as many
> as possible. Is that part clear? I know it is not what you do,
> but there are use cases for that (Read John's response).
> Now assuming someone wants this and some entries failed;
> how do you tell user space back what was actually updated vs not?
> You could return a code which says "partial success".
> Forget whether the table is keyed or indexed but if you wanted
> to return more detailed info you would return an array/vector of some
> sort with status code per entry. Something netlink cant do.
> Is that a better description?
>
>> Are you trying to install
>> FDB entry into both SW and HW at same time?
>
>
>
> What is wrong with installing on both hardware and software? The
> point was to identify what kind of policies could be requested by
> the user; but even for the bridge why is it bad that i ask for
> both master&self?
> It is something I can do today with none of these patches.
>
>> And then do a bunch in a
>> batch? I'm saying use MASTER for SW and SELF for HW in two steps,
>
>
> But that would be enforcing your policy on me.
Ok, I get it now. I'm looking forward to see what solution people
come up with to solve this.
>
>> if
>> you want FDB entry installed in both Sw and HW. Check your return
>> code each step. Batch all to HW first, then batch all that PASSED to
>> SW. I don't even know really why you're trying to install to both HW
>> and SW. Install it to HW and be done. fdb_dump will set HW entries
>> via SELF.
>>
>
> First off: bad performance, but your call to do it that way
> (just please please dont enforce it on me;->)
>
> Lets take the hardware batching you mentioned above and see if
> i can help to clarify in the third policy choice (continue-on-failure).
> Lets say you have a keyed table such as the fdb table is.
> You send 10 entries to be created/added in hardware. #3 and #5 failed
> because you made a mistake and sent them with the same key. #9 and #10
> failed because the hardware doesnt have any more space.
> we didnt stop and go back for #3 and #5 because the user told
> us to continue and do the rest when we fail. And s/he did that because
> she wanted to put as many entries in hardware as possible without
> necessarily needing to know how much space exists.
>
>
>> Ah, Jamal, look again at patches 13-17/17 in last v3 set. That was a
>> big steaming snickerdoodle just for you! Now you can push policy
>> knobs down to port driver and or bridge to fine tune what ever you
>> want. You'll find knobs for learning, flooding, learning sync to hw,
>> etc. I thought you even ACKed some of these.
>
>
> I think it almost there.
> What you are missing is the policy decision to only sync when i
> say so. Having an ndo_ops is a necessity but i dont want the driver
> to decide for me just because it can ;->
> Telling hardware to learn is instructing it to self update its entries
> based on source lookup failure. That is distinctly different from
> telling to sync to the kernel. So if you add that knob we are in good
> shape.
It's there: IFLA_BRPORT_LEARNING_SYNC. From iproute2:
$ bridge -d link show dev swp1
2: swp1 state UNKNOWN : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
master br0 state forwarding priority 32 cost 2
hairpin off guard off root_block off fastleave off learning off flood off
2: swp1 state UNKNOWN : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0
learning on learning_sync on hwmode swdev
Turn it off:
$ bridge link set dev swp1 hwmode swdev learning_sync off
And now:
$ bridge -d link show dev swp1
2: swp1 state UNKNOWN : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
master br0 state forwarding priority 32 cost 2
hairpin off guard off root_block off fastleave off learning off flood off
2: swp1 state UNKNOWN : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0
learning on learning_sync off hwmode swdev
> cheers,
> jamal
>
>
>> a) above knob is 14/17
>> patch, b) above is using existing learning knob on bridge, c) above I
>> don't get...no point in syncing that direction.
>>
>
^ permalink raw reply
* Re: [PATCH RFC net-next] net: Add GRO support for GRE tunneling of TEB packets
From: Or Gerlitz @ 2014-11-27 6:51 UTC (permalink / raw)
To: Tom Herbert
Cc: Or Gerlitz, David S. Miller, Linux Netdev List, Eric Dumazet,
H.K. Jerry Chu
In-Reply-To: <CA+mtBx_-TU+ktWY85bJ1gJOMZD1BOW5hbj=JdEHV5FohYxdjAg@mail.gmail.com>
On Wed, Nov 26, 2014 at 5:44 PM, Tom Herbert <therbert@google.com> wrote:
> On Wed, Nov 26, 2014 at 7:08 AM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
>> Add the missing parts in the gre gro handlers when the inner protocol
>> is ETH_P_TEB which is the case for OVS based GRE tunneling.
> I don't think this is the right approach. It would probably be better
> to a add a gro_receive handler for ETH_P_TEB and then you wouldn't
> need to modify GRE path with special case code. That would also be
> applicable in geneve.
Makes sense, I'll do that, thanks for the feedback.
^ permalink raw reply
* Re: [PATCH net-next v4] ipvlan: Initial check-in of the IPVLAN driver.
From: Mahesh Bandewar @ 2014-11-27 6:55 UTC (permalink / raw)
To: Toshiaki Makita
Cc: netdev, Eric Dumazet, Maciej Zenczykowski, Laurent Chavey,
Tim Hockin, David Miller, Brandon Philips, Pavel Emelianov
In-Reply-To: <5476859E.609@lab.ntt.co.jp>
On Wed, Nov 26, 2014 at 5:59 PM, Toshiaki Makita
<makita.toshiaki@lab.ntt.co.jp> wrote:
> On 2014/11/27 2:05, Mahesh Bandewar wrote:
>> On Tue, Nov 25, 2014 at 10:41 PM, Toshiaki Makita
>> <makita.toshiaki@lab.ntt.co.jp> wrote:
>>> Hi Mahesh,
>>>
>>> I found that deleting the last ipvlan device triggers WARN_ON() in
>>> rtmsg_ifinfo().
>>> ipvlan_nl_fillinfo() seems to return -EINVAL in that case.
>>>
>>>> +static int ipvlan_nl_fillinfo(struct sk_buff *skb,
>>>> + const struct net_device *dev)
>>>> +{
>>>> + struct ipvl_dev *ipvlan = netdev_priv(dev);
>>>> + struct ipvl_port *port = ipvlan_port_get_rtnl(ipvlan->phy_dev);
>>>> + int ret = -EINVAL;
>>>> +
>>>> + if (!port)
>>>> + goto err;
>>>> +
>>>> + ret = -EMSGSIZE;
>>>> + if (nla_put_u16(skb, IFLA_IPVLAN_MODE, port->mode))
>>>> + goto err;
>>>> +
>>>> + return 0;
>>>> +
>>>> +err:
>>>> + return ret;
>>>> +}
>>>
>>> rollback_registered_many() calls rtmsg_ifinfo() after calling ndo_uninit().
>>> ndo_uninit() (ipvlan_uninit() -> ipvlan_port_destroy() ->
>>> netdev_rx_handler_unregister()) sets rx_handler_data into NULL.
>>> So, we cannot dereference "port" in ipvlan_nl_fillinfo().
>>>
>> Calling fillinfo() after calling uninit() seems pointless on any
>> device.
>
> bonding needs calling rtmsg_ifinfo() after calling ndo_uninit().
> 56bfa7ee7c88 ("unregister_netdevice : move RTM_DELLINK to until after
> ndo_uninit")
>
Thanks I'll take a look.
>> But how are you hitting this case? Can you share the command
>> sequence with me?
>
> # ip link add link eth0 name ipvl0 type ipvlan
> # ip link del ipvl0
>
Yes, I could reproduce the issue when the master device is a bond.
> Thanks,
> Toshiaki Makita
>
>>
>> Thanks,
>> --mahesh..
>>
>>> Maybe "mode" should belong to struct ipvl_dev?
>>>
>>> Thanks,
>>> Toshiaki Makita
>
^ permalink raw reply
* Re: [patch net-next v3 09/17] bridge: add API to notify bridge driver of learned FBD on offloaded device
From: Scott Feldman @ 2014-11-27 7:03 UTC (permalink / raw)
To: Arad, Ronen; +Cc: netdev@vger.kernel.org
In-Reply-To: <E4CD12F19ABA0C4D8729E087A761DC3505D7E13E@ORSMSX101.amr.corp.intel.com>
On Tue, Nov 25, 2014 at 9:37 PM, Arad, Ronen <ronen.arad@intel.com> wrote:
>> >>>
>> >>> Is there any case where this fdb entry gets re-used and is no
>> >>> longer added by an external learning? Should we clear this flag somewhere?
>> >>
>> >> Once the FDB entry is marked "added_by_external_learn" it stays
>> >> marked as such until removed by aging cleanup process (or flushed
>> >> due to interface down, etc). If aged out (and now deleted), the
>> >> FDB entry may come back either by SW learn or by HW learn. If SW
>> >> learn comes first, and then HW learn, HW learn will override and
>> >> mark the existing FDB entry "added_by_external_learn". So there is
>> >> take-over by HW but no give-back to SW. And there is no explicit
>> >> clearing of the mark short of deleting the FDB entry. The mark is
>> >> mostly for letting user's know which FDB entries where learned by
>> >> HW and synced to the bridge's FDB.
>> >
>> > Thanks, makes sense now. This is probably obvious in this context,
>> > but maybe it would not hurt to come up with a documentation that
>> > describe the offload API, FDB entry lifetime and HW/SW ownership etc...
>>
>> I have an updated Documentation/networking/switchdev.txt that covers
>> the swdev APIs and usage and notes, but Jiri is being stingy with it.
>> Will get this out, either in v4 or follow-on patches. There is enough
>> going on just with L2 offload that we're going to need some good
>> documentation to guide implementers.
>> --
>
> To control the lifetime of an externally learned FDB entry, the bridge shall provide an API for the switch driver to update the freshness of externally learned entries. Otherwise, the bridge aging will age entries which are currently or frequently used by the HW.
> Is this covered in the updated document?
> Is this functionality planned for v4?
Hi Ronen,
It's already there: driver calls br_fdb_external_learn_add() to
refresh FBD entry, which updates the fdb->updated and fdb->used
timestamps, preventing bridge from prematurely aging out the entry.
We'll make sure that detail gets in the doc. It's up to the driver on
how frequently it calls br_fdb_external_learn_add(). Maybe it just
blindly makes the call every 1s. That's what rocker driver does (as
long as the FDB entry continues to get hits). From the user's
perspective, 1s update is nice when looking at the stats dump for
fdbs, since the timestamps are in secs.
-scott
^ permalink raw reply
* Re: Multiple DSA switch on shared MII
From: Rajib Karmakar @ 2014-11-27 7:18 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev
In-Reply-To: <CAOi_9k_3+9U4q=SHdeEJOi_efHkRvYdTQ=UBqZtafgDAv_oOHg@mail.gmail.com>
This could be a naive question; but can I add all LAN and WAN
interfaces in a single DSA switch (one cpu port, one netdev)?
^ permalink raw reply
* Re: [PATCH rfc] packet: zerocopy packet_snd
From: Michael S. Tsirkin @ 2014-11-27 7:27 UTC (permalink / raw)
To: Willem de Bruijn
Cc: Network Development, David Miller, Eric Dumazet, Daniel Borkmann
In-Reply-To: <CA+FuTSf_qiO964ZK1gB9skd1iQMj3iodcccscCt=vo6j92MsuA@mail.gmail.com>
On Wed, Nov 26, 2014 at 06:05:16PM -0500, Willem de Bruijn wrote:
> On Wed, Nov 26, 2014 at 4:20 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Wed, Nov 26, 2014 at 02:59:34PM -0500, Willem de Bruijn wrote:
> >> > The main problem with zero copy ATM is with queueing disciplines
> >> > which might keep the socket around essentially forever.
> >> > The case was described here:
> >> > https://lkml.org/lkml/2014/1/17/105
> >> > and of course this will make it more serious now that
> >> > more applications will be able to do this, so
> >> > chances that an administrator enables this
> >> > are higher.
> >>
> >> The denial of service issue raised there, that a single queue can
> >> block an entire virtio-net device, is less problematic in the case of
> >> packet sockets. A socket can run out of sk_wmem_alloc, but a prudent
> >> application can increase the limit or use separate sockets for
> >> separate flows.
> >
> > Sounds like this interface is very hard to use correctly.
>
> Actually, this socket alloc issue is the same for zerocopy and
> non-zerocopy. Packets can be held in deep queues at which point
> the packet socket is blocked. This is accepted behavior.
>
> >From the above thread:
>
> "It's ok for non-zerocopy packet to be blocked since VM1 thought the
> packets has been sent instead of pending in the virtqueue. So VM1 can
> still send packet to other destination."
>
> This is very specific to virtio and vhost-net. I don't think that that
> concern applies to a packet interface.
Well, you are obviously building the interface with some use-case in mind.
Let's try to make it work for multiple use-cases.
So at some level, you are right. The issue is not running out of wmem.
But I think I'm right too - this is hard to use correctly.
I think the difference is that with your patch, application
can't reuse the memory until packet is transmitted, otherwise junk goes
out on the network. Even closing the socket won't help.
Is this true?
I see this as a problem.
I'm trying to figure out how would one use this interface, one obvious
use would be to tunnel out raw packets directly from VM memory.
For this application, a zero copy packet never completing is a problem:
at minimum, you want to be able to remove the device, which
translates to a requirement that closing the socket effectively stops
using userspace memory. In case you want to be able to run e.g. a watchdog,
ability to specify a deadline also seems benefitial.
> Another issue, though, is that the method currently really only helps
> TSO because ll other paths cause a deep copy. There are more use
> cases once it can send up to 64KB MTU over loopback or send out
> GSO datagrams without triggering skb_copy_ubufs. I have not looked
> into how (or if) that can be achieved yet.
I think this was done intentionally at some point,
try to look at git history to find out the reasons.
> >
> >> > One possible solution is some kind of timer orphaning frags
> >> > for skbs that have been around for too long.
> >>
> >> Perhaps this can be approximated without an explicit timer by calling
> >> skb_copy_ubufs on enqueue whenever qlen exceeds a threshold value?
> >
> > Not sure. I'll have to see that patch to judge.
^ permalink raw reply
* RE: [patch net-next v3 09/17] bridge: add API to notify bridge driver of learned FBD on offloaded device
From: Arad, Ronen @ 2014-11-27 7:37 UTC (permalink / raw)
To: Scott Feldman; +Cc: netdev@vger.kernel.org
In-Reply-To: <CAE4R7bC9o4ucO_Erb0tU4EwJNYj8SrapbKxNWvUTL8YD=RMBJQ@mail.gmail.com>
> -----Original Message-----
> From: Scott Feldman [mailto:sfeldma@gmail.com]
> Sent: Wednesday, November 26, 2014 11:04 PM
> To: Arad, Ronen
> Cc: netdev@vger.kernel.org
> Subject: Re: [patch net-next v3 09/17] bridge: add API to notify bridge driver
> of learned FBD on offloaded device
>
> On Tue, Nov 25, 2014 at 9:37 PM, Arad, Ronen <ronen.arad@intel.com>
> wrote:
> >> >>>
> >> >>> Is there any case where this fdb entry gets re-used and is no
> >> >>> longer added by an external learning? Should we clear this flag
> somewhere?
> >> >>
> >> >> Once the FDB entry is marked "added_by_external_learn" it stays
> >> >> marked as such until removed by aging cleanup process (or flushed
> >> >> due to interface down, etc). If aged out (and now deleted), the
> >> >> FDB entry may come back either by SW learn or by HW learn. If SW
> >> >> learn comes first, and then HW learn, HW learn will override and
> >> >> mark the existing FDB entry "added_by_external_learn". So there
> >> >> is take-over by HW but no give-back to SW. And there is no
> >> >> explicit clearing of the mark short of deleting the FDB entry.
> >> >> The mark is mostly for letting user's know which FDB entries where
> >> >> learned by HW and synced to the bridge's FDB.
> >> >
> >> > Thanks, makes sense now. This is probably obvious in this context,
> >> > but maybe it would not hurt to come up with a documentation that
> >> > describe the offload API, FDB entry lifetime and HW/SW ownership etc...
> >>
> >> I have an updated Documentation/networking/switchdev.txt that covers
> >> the swdev APIs and usage and notes, but Jiri is being stingy with it.
> >> Will get this out, either in v4 or follow-on patches. There is
> >> enough going on just with L2 offload that we're going to need some
> >> good documentation to guide implementers.
> >> --
> >
> > To control the lifetime of an externally learned FDB entry, the bridge shall
> provide an API for the switch driver to update the freshness of externally
> learned entries. Otherwise, the bridge aging will age entries which are
> currently or frequently used by the HW.
> > Is this covered in the updated document?
> > Is this functionality planned for v4?
>
> Hi Ronen,
>
> It's already there: driver calls br_fdb_external_learn_add() to refresh FBD
> entry, which updates the fdb->updated and fdb->used timestamps,
> preventing bridge from prematurely aging out the entry.
> We'll make sure that detail gets in the doc. It's up to the driver on how
> frequently it calls br_fdb_external_learn_add(). Maybe it just blindly makes
> the call every 1s. That's what rocker driver does (as long as the FDB entry
> continues to get hits). From the user's perspective, 1s update is nice when
> looking at the stats dump for fdbs, since the timestamps are in secs.
>
> -scott
Hi Scott,
Thanks. This should work. I overlooked that but now I see it in the code with a clear comment.
-ronen
^ permalink raw reply
* Re: 3.12.33 Bug with ipvs
From: Julian Anastasov @ 2014-11-27 8:08 UTC (permalink / raw)
To: Smart Weblications GmbH - Florian Wiessner; +Cc: netdev
In-Reply-To: <54763E3F.4020306@smart-weblications.de>
Hello,
On Wed, 26 Nov 2014, Smart Weblications GmbH - Florian Wiessner wrote:
> Hi netdev,
>
> On 3.12.33 i see this every 3 hours or so on a box with ip_vs running with a
> setup which made no problems on 3.10.40. Could someone give me hints how to
> debug this? It seems to happen instantly, when i add ip_vs_ftp and have some nat
> rules. Setup is like this:
>
> [13230.431740] RIP [<ffffffff814ff2fc>] xfrm_selector_match+0x25/0x2f6
> [13230.431772] RSP <ffff88083fd83a68>
> [13230.431795] CR2: 00000000000600d0
> [13230.432240] ---[ end trace 103912aa204977dc ]---
>
> node01:/ocfs2/usr/src/linux-3.12.33/scripts# ./decodecode </tmp/oops.log
> [13230.431464] Code: 5d 41 5e 41 5f c3 41 55 66 83 fa 02 41 54 55 48 89 fd 53 48
> 89 f3 41 50 74 11 31 c0 66 83 fa 0a 0f 85 ce 02 00 00 e9 fd 00 00 00 <0f> b6 47
> 2a 8b 17 8b 76 18 84 c0 74 1a b9 20 00 00 00 31 f2 29
> All code
> ========
> 0: 5d pop %rbp
> 1: 41 5e pop %r14
> 3: 41 5f pop %r15
> 5: c3 retq
> 6: 41 55 push %r13
> 8: 66 83 fa 02 cmp $0x2,%dx
> c: 41 54 push %r12
> e: 55 push %rbp
> f: 48 89 fd mov %rdi,%rbp
> 12: 53 push %rbx
> 13: 48 89 f3 mov %rsi,%rbx
> 16: 41 50 push %r8
> 18: 74 11 je 0x2b
> 1a: 31 c0 xor %eax,%eax
> 1c: 66 83 fa 0a cmp $0xa,%dx
> 20: 0f 85 ce 02 00 00 jne 0x2f4
> 26: e9 fd 00 00 00 jmpq 0x128
> 2b:* 0f b6 47 2a movzbl 0x2a(%rdi),%eax <-- trapping
> instruction
Above instruction is 'sel->prefixlen_d' from
the addr4_match call in __xfrm4_selector_match. Looks like
we dereference sel (%rdi) with bad value of 00000000000600a6.
xfrm_sk_policy_lookup() provides &pol->selector to
xfrm_selector_match, so pol has a bad value. I don't remember
for such problem, not sure if the 3-hour period is some timer
in xfrm.
> Could someone shed some light on the decoded output and point me somewhere so i
> can debug this further?
If noone else has idea what can be wrong, can you try
some kernels between 3.10.40 and 3.12.33 or even some lastest
kernel?
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH rfc] packet: zerocopy packet_snd
From: Jason Wang @ 2014-11-27 9:10 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Willem de Bruijn, Network Development, David Miller, Eric Dumazet,
Daniel Borkmann
In-Reply-To: <20141126211748.GA11904@redhat.com>
On Thu, Nov 27, 2014 at 5:17 AM, Michael S. Tsirkin <mst@redhat.com>
wrote:
> On Wed, Nov 26, 2014 at 02:59:34PM -0500, Willem de Bruijn wrote:
>> > The main problem with zero copy ATM is with queueing disciplines
>> > which might keep the socket around essentially forever.
>> > The case was described here:
>> > https://lkml.org/lkml/2014/1/17/105
>> > and of course this will make it more serious now that
>> > more applications will be able to do this, so
>> > chances that an administrator enables this
>> > are higher.
>>
>> The denial of service issue raised there, that a single queue can
>> block an entire virtio-net device, is less problematic in the case
>> of
>> packet sockets. A socket can run out of sk_wmem_alloc, but a prudent
>> application can increase the limit or use separate sockets for
>> separate flows.
>
> Socket per flow? Maybe just use TCP then? increasing the limit
> sounds like a wrong solution, it hurts security.
>
>> > One possible solution is some kind of timer orphaning frags
>> > for skbs that have been around for too long.
>>
>> Perhaps this can be approximated without an explicit timer by
>> calling
>> skb_copy_ubufs on enqueue whenever qlen exceeds a threshold value?
>
> Hard to say. Will have to see that patch to judge how robust this is.
This could not work, consider if the threshold is greater than vring
size
or vhost_net pending limit, transmission may still be blocked.
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Bjørn Mork @ 2014-11-27 9:16 UTC (permalink / raw)
To: Enrico Mioso; +Cc: youtux, linux-usb, netdev
In-Reply-To: <alpine.LNX.2.03.1411262250160.4356@gmail.com>
Enrico Mioso <mrkiko.rs@gmail.com> writes:
> I am sorry for the indecent capture - but I didn't manage to get a
> better one till now.
> We modified the driver: but I wanted to be sure ... is this 32-bit NCM?
Yes, it looks OK to me. I have only looked at it manually, so I could
have missed something. But the signatures and header field lengths seem
fine.
I did notice one issue though, which might be related to more generic
alignment bugs in the driver?
The modem sends this. Notice how the single ethernet frame inside starts
at 0072, skipping 2 unused bytes, making the IP packet start at a 4-byte
aligned 0080:
0040 6e 63 6d 68 10 00 c7 00 cd 00 00 00 10 00 00 00 ncmh............
0050 6e 63 6d 30 20 00 00 00 00 00 00 00 00 00 00 00 ncm0 ...........
0060 32 00 00 00 9b 00 00 00 00 00 00 00 00 00 00 00 2...............
0070 00 00 0c 5b 8f 27 9a 64 4c 54 99 45 e5 d5 08 00 ...[.'.dLT.E....
0080 45 00 00 8d 05 7f 40 00 33 06 af d8 95 9a a7 5b E.....@.3......[
0090 0a 1f 4a ff 01 bb ce 5c c0 d5 a0 ba 8c 57 85 63 ..J....\.....W.c
00a0 80 18 09 e6 35 0b 00 00 01 01 08 0a 4d 8b 3f fe ....5.......M.?.
00b0 00 78 a8 a7 16 1a 21 17 60 0e 73 21 c7 d6 77 cd .x....!.`.s!..w.
00c0 92 00 69 26 54 28 cb 19 25 2a 16 6b 82 6b bf ba ..i&T(..%*.k.k..
00d0 46 a7 8a 6e eb 36 59 25 eb 9b e2 bb 4b 53 f2 4d F..n.6Y%....KS.M
00e0 ce 11 dd 88 06 e8 23 24 8a 96 03 d9 61 31 34 9b ......#$....a14.
00f0 68 f3 e9 5c fd d1 77 5f 18 75 fd 10 4d cb e7 29 h..\..w_.u..M..)
0100 96 89 3d 75 fe 11 15 82 28 88 5b ba b0 ..=u....(.[..
While we, after a large number of unused 0 bytes due to the fixed size
NDP allocation, start the ethernet frame at 01a8, making the IP packet
start at a 2-byte aligned offset at 01b6:
0040 6e 63 6d 68 10 00 d5 00 aa 01 00 00 10 00 00 00 ncmh............
0050 6e 63 6d 30 20 00 00 00 00 00 00 00 00 00 00 00 ncm0 ...........
0060 68 01 00 00 42 00 00 00 00 00 00 00 00 00 00 00 h...B...........
0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01a0 00 00 00 00 00 00 00 00 4c 54 99 45 e5 d5 0c 5b ........LT.E...[
01b0 8f 27 9a 64 08 00 45 00 00 34 84 0b 40 00 40 06 .'.d..E..4..@.@.
01c0 24 a5 0a 1f 4a ff 95 9a a7 5b ce 5c 01 bb 8c 57 $...J....[.\...W
01d0 85 63 c0 d5 a1 13 80 10 03 59 0f 23 00 00 01 01 .c.......Y.#....
01e0 08 0a 00 79 00 6f 4d 8b 3f fe ...y.oM.?.
This is not so nice, and I do wonder if it is according to the requested
alignment from the modem? If not, then that is more likely to break
stuff than the 16-bit vs 32-bit header issue.
Bjørn
^ permalink raw reply
* [PATCH net] rtnetlink: release net refcnt on error in do_setlink()
From: Nicolas Dichtel @ 2014-11-27 9:16 UTC (permalink / raw)
To: davem; +Cc: netdev, Nicolas Dichtel, Eric W. Biederman
rtnl_link_get_net() holds a reference on the 'struct net', we need to release
it in case of error.
CC: Eric W. Biederman <ebiederm@xmission.com>
Fixes: b51642f6d77b ("net: Enable a userns root rtnl calls that are safe for unprivilged users")
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
net/core/rtnetlink.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index b9b7dfaf202b..76321ea442c3 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1498,6 +1498,7 @@ static int do_setlink(const struct sk_buff *skb,
goto errout;
}
if (!netlink_ns_capable(skb, net->user_ns, CAP_NET_ADMIN)) {
+ put_net(net);
err = -EPERM;
goto errout;
}
--
2.1.0
^ permalink raw reply related
* Re: Is this 32-bit NCM?
From: Enrico Mioso @ 2014-11-27 9:22 UTC (permalink / raw)
To: Bjørn Mork; +Cc: youtux, linux-usb, netdev, Alex Strizhevsky
In-Reply-To: <87ppc957h1.fsf@nemi.mork.no>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 4772 bytes --]
So ... might be this is happening even in 16 bit mode?
With our test device we are having no luck: the firmware now at least prints
dsflowrpt messages, but we seem to not go farther than this.
so - what should we try in your opinion? Go try with the 16 bit mode and try to
fix the alignment issues?
Any help would be greatly apreciated ... this is becoming a personal challenge,
even facing a possibly growing number of devices.
On Thu, 27 Nov 2014, Bjørn Mork wrote:
==Date: Thu, 27 Nov 2014 10:16:26
==From: Bjørn Mork <bjorn@mork.no>
==To: Enrico Mioso <mrkiko.rs@gmail.com>
==Cc: youtux@gmail.com, linux-usb@vger.kernel.org, netdev@vger.kernel.org
==Subject: Re: Is this 32-bit NCM?
==
==Enrico Mioso <mrkiko.rs@gmail.com> writes:
==
==> I am sorry for the indecent capture - but I didn't manage to get a
==> better one till now.
==> We modified the driver: but I wanted to be sure ... is this 32-bit NCM?
==
==
==Yes, it looks OK to me. I have only looked at it manually, so I could
==have missed something. But the signatures and header field lengths seem
==fine.
==
==I did notice one issue though, which might be related to more generic
==alignment bugs in the driver?
==
==The modem sends this. Notice how the single ethernet frame inside starts
==at 0072, skipping 2 unused bytes, making the IP packet start at a 4-byte
==aligned 0080:
==
==0040 6e 63 6d 68 10 00 c7 00 cd 00 00 00 10 00 00 00 ncmh............
==0050 6e 63 6d 30 20 00 00 00 00 00 00 00 00 00 00 00 ncm0 ...........
==0060 32 00 00 00 9b 00 00 00 00 00 00 00 00 00 00 00 2...............
==0070 00 00 0c 5b 8f 27 9a 64 4c 54 99 45 e5 d5 08 00 ...[.'.dLT.E....
==0080 45 00 00 8d 05 7f 40 00 33 06 af d8 95 9a a7 5b E.....@.3......[
==0090 0a 1f 4a ff 01 bb ce 5c c0 d5 a0 ba 8c 57 85 63 ..J....\.....W.c
==00a0 80 18 09 e6 35 0b 00 00 01 01 08 0a 4d 8b 3f fe ....5.......M.?.
==00b0 00 78 a8 a7 16 1a 21 17 60 0e 73 21 c7 d6 77 cd .x....!.`.s!..w.
==00c0 92 00 69 26 54 28 cb 19 25 2a 16 6b 82 6b bf ba ..i&T(..%*.k.k..
==00d0 46 a7 8a 6e eb 36 59 25 eb 9b e2 bb 4b 53 f2 4d F..n.6Y%....KS.M
==00e0 ce 11 dd 88 06 e8 23 24 8a 96 03 d9 61 31 34 9b ......#$....a14.
==00f0 68 f3 e9 5c fd d1 77 5f 18 75 fd 10 4d cb e7 29 h..\..w_.u..M..)
==0100 96 89 3d 75 fe 11 15 82 28 88 5b ba b0 ..=u....(.[..
==
==
==
==While we, after a large number of unused 0 bytes due to the fixed size
==NDP allocation, start the ethernet frame at 01a8, making the IP packet
==start at a 2-byte aligned offset at 01b6:
==
==0040 6e 63 6d 68 10 00 d5 00 aa 01 00 00 10 00 00 00 ncmh............
==0050 6e 63 6d 30 20 00 00 00 00 00 00 00 00 00 00 00 ncm0 ...........
==0060 68 01 00 00 42 00 00 00 00 00 00 00 00 00 00 00 h...B...........
==0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==0110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==0120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==0130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==0150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==0160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==0170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==0180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==0190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
==01a0 00 00 00 00 00 00 00 00 4c 54 99 45 e5 d5 0c 5b ........LT.E...[
==01b0 8f 27 9a 64 08 00 45 00 00 34 84 0b 40 00 40 06 .'.d..E..4..@.@.
==01c0 24 a5 0a 1f 4a ff 95 9a a7 5b ce 5c 01 bb 8c 57 $...J....[.\...W
==01d0 85 63 c0 d5 a1 13 80 10 03 59 0f 23 00 00 01 01 .c.......Y.#....
==01e0 08 0a 00 79 00 6f 4d 8b 3f fe ...y.oM.?.
==
==
==This is not so nice, and I do wonder if it is according to the requested
==alignment from the modem? If not, then that is more likely to break
==stuff than the 16-bit vs 32-bit header issue.
==
==
==
==Bjørn
==
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Enrico Mioso @ 2014-11-27 9:45 UTC (permalink / raw)
To: Bjørn Mork; +Cc: youtux, alexxst, linux-usb, netdev
In-Reply-To: <87ppc957h1.fsf@nemi.mork.no>
Ok - we can arrive to some ocnclusions regarding the E3272.
First of all - the modem seems buggy enough to not be able to handle requests
for different formats. You need to unplug and re-plug it, but this is onlyan
impression and is reasonable.
Then - the modem will accept to ndisdup the connection with
at^ndisdup=1,1,"internet"
but - if we use huawei_cdc_ncm + cdc_ncm we have no flow handling messages and
the modem stops here.
If we use the cdc_ncm 32-bit driver (modified) we get lotfs of
^dsflorpt
that's how it should be.
So I think we can say that something is changing.
Then there's the alignment problem you mentioned in your previous reply. And
this is hard to solve.
could you try to help me understand where the problem is?
I feel like we are very close to the solution but something isn't working.
Or might be just try to change the 16 bit driver?
http://www.gstorm.eu/cdc_ncm.c
^ permalink raw reply
* Re: [PATCH net] bpf: x86: fix epilogue generation for eBPF programs
From: Daniel Borkmann @ 2014-11-27 9:52 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, Zi Shen Lim, Eric Dumazet, H. Peter Anvin,
Thomas Gleixner, Ingo Molnar, netdev, linux-kernel
In-Reply-To: <1417064546-4129-1-git-send-email-ast@plumgrid.com>
On 11/27/2014 06:02 AM, Alexei Starovoitov wrote:
> 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.
>
> Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
> ---
> Note, this bug is applicable only to native eBPF programs
> which first were introduced in 3.18, so no need to send it
> to stable and therefore no 'Fixes' tag.
Btw, even if it's not sent to -stable, a 'Fixes:' tag is useful
information for backporting and regression tracking, preferably
always mentioned where it can clearly be identified.
> arm64 JIT has the same problem, but the fix is not as trivial,
> so will be done as separate patch.
>
> Since 3.18 can only load eBPF programs and cannot execute them,
> this patch can even be done in net-next only, but I think it's worth
> to apply it to 3.18(net), so that JITed output for native eBPF
> programs is correct when bpf syscall loads it with net.core.bpf_jit_enable=2
Yes, sounds good to me, the condition insn_cnt - 1 is still held
with BPF to eBPF transformations.
> arch/x86/net/bpf_jit_comp.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
> index 3f62734..7e90244 100644
> --- a/arch/x86/net/bpf_jit_comp.c
> +++ b/arch/x86/net/bpf_jit_comp.c
> @@ -178,7 +178,7 @@ static void jit_fill_hole(void *area, unsigned int size)
> }
>
> struct jit_context {
> - unsigned int cleanup_addr; /* epilogue code offset */
> + int cleanup_addr; /* epilogue code offset */
Why this type change here? This seems a bit out of context (I would
have expected a mention of this in the commit message, otherwise).
> bool seen_ld_abs;
> };
>
> @@ -192,6 +192,7 @@ static int do_jit(struct bpf_prog *bpf_prog, int *addrs, u8 *image,
> struct bpf_insn *insn = bpf_prog->insnsi;
> int insn_cnt = bpf_prog->len;
> bool seen_ld_abs = ctx->seen_ld_abs | (oldproglen == 0);
> + bool seen_exit = false;
> u8 temp[BPF_MAX_INSN_SIZE + BPF_INSN_SAFETY];
> int i;
> int proglen = 0;
> @@ -854,10 +855,11 @@ common_load:
> goto common_load;
>
> case BPF_JMP | BPF_EXIT:
> - if (i != insn_cnt - 1) {
> + if (seen_exit) {
> jmp_offset = ctx->cleanup_addr - addrs[i];
> goto emit_jmp;
> }
> + seen_exit = true;
> /* update cleanup_addr */
> ctx->cleanup_addr = proglen;
> /* mov rbx, qword ptr [rbp-X] */
>
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Bjørn Mork @ 2014-11-27 10:03 UTC (permalink / raw)
To: Enrico Mioso; +Cc: youtux, alexxst, linux-usb, netdev
In-Reply-To: <alpine.LNX.2.03.1411271037050.9464@gmail.com>
Enrico Mioso <mrkiko.rs@gmail.com> writes:
> Ok - we can arrive to some ocnclusions regarding the E3272.
> First of all - the modem seems buggy enough to not be able to handle requests
> for different formats. You need to unplug and re-plug it, but this is onlyan
> impression and is reasonable.
>
> Then - the modem will accept to ndisdup the connection with
> at^ndisdup=1,1,"internet"
> but - if we use huawei_cdc_ncm + cdc_ncm we have no flow handling messages and
> the modem stops here.
> If we use the cdc_ncm 32-bit driver (modified) we get lotfs of
> ^dsflorpt
> that's how it should be.
> So I think we can say that something is changing.
> Then there's the alignment problem you mentioned in your previous reply. And
> this is hard to solve.
> could you try to help me understand where the problem is?
> I feel like we are very close to the solution but something isn't working.
> Or might be just try to change the 16 bit driver?
If you use a recent version of the driver as a basis, then you get the
CDC NCM NTB parameters in sysfs (if not, then you need to enable
debugging and look in the log for these values). For example:
bjorn@nemi:~$ grep . /sys/class/net/wwan0/cdc_ncm/*
/sys/class/net/wwan0/cdc_ncm/bmNtbFormatsSupported:0x0001
/sys/class/net/wwan0/cdc_ncm/dwNtbInMaxSize:15360
/sys/class/net/wwan0/cdc_ncm/dwNtbOutMaxSize:15360
/sys/class/net/wwan0/cdc_ncm/min_tx_pkt:13824
/sys/class/net/wwan0/cdc_ncm/rx_max:15360
/sys/class/net/wwan0/cdc_ncm/tx_max:15360
/sys/class/net/wwan0/cdc_ncm/tx_timer_usecs:400
/sys/class/net/wwan0/cdc_ncm/wNdpInAlignment:4
/sys/class/net/wwan0/cdc_ncm/wNdpInDivisor:1
/sys/class/net/wwan0/cdc_ncm/wNdpInPayloadRemainder:0
/sys/class/net/wwan0/cdc_ncm/wNdpOutAlignment:4
/sys/class/net/wwan0/cdc_ncm/wNdpOutDivisor:32
/sys/class/net/wwan0/cdc_ncm/wNdpOutPayloadRemainder:0
/sys/class/net/wwan0/cdc_ncm/wNtbOutMaxDatagrams:32
The possible problem I am thinking of is proper handling of the
wNdp*PayloadRemainder values. See section 3.3.4 "NCM Ethernet Frame
Alignment" in the spec. Which is confusing as hell, but if I understand
it correctly then we are supposed to align the start of the IP packets
(the "payload", _not_ the ethernet frame) to a whole wNdp*Divisor number
as long as the wNdp*PayloadRemainder is 0.
Bjørn
^ permalink raw reply
* [PATCH] ixgbe, ixgbevf: Add new mbox API to enable MC promiscuous mode
From: Hiroshi Shimamoto @ 2014-11-27 10:39 UTC (permalink / raw)
To: e1000-devel@lists.sourceforge.net
Cc: netdev@vger.kernel.org, Choi, Sy Jong, Hayato Momma,
linux-kernel@vger.kernel.org
From: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
The limitation of the number of multicast address for VF is not enough
for the large scale server with SR-IOV feature.
IPv6 requires the multicast MAC address for each IP address to handle
the Neighbor Solicitation message.
We couldn't assign over 30 IPv6 addresses to a single VF interface.
The easy way to solve this is enabling multicast promiscuous mode.
It is good to have a functionality to enable multicast promiscuous mode
for each VF from VF driver.
This patch introduces the new mbox API, IXGBE_VF_SET_MC_PROMISC, to
enable/disable multicast promiscuous mode in VF. If multicast promiscuous
mode is enabled the VF can receive all multicast packets.
With this patch, the ixgbevf driver automatically enable multicast
promiscuous mode when the number of multicast addresses is over than 30
if possible.
This also bump the API version up to 1.2 to check whether the API,
IXGBE_VF_SET_MC_PROMISC is available.
Signed-off-by: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
CC: Choi, Sy Jong <sy.jong.choi@intel.com>
Reviewed-by: Hayato Momma <h-momma@ce.jp.nec.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 1 +
drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h | 4 ++
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 80 +++++++++++++++++++++++
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 13 +++-
drivers/net/ethernet/intel/ixgbevf/mbx.h | 4 ++
drivers/net/ethernet/intel/ixgbevf/vf.c | 29 +++++++-
drivers/net/ethernet/intel/ixgbevf/vf.h | 1 +
7 files changed, 130 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
index 5032a60..2a5e3d3 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -144,6 +144,7 @@ struct vf_data_storage {
u16 vlans_enabled;
bool clear_to_send;
bool pf_set_mac;
+ bool vf_mc_promisc;
u16 pf_vlan; /* When set, guest VLAN config not allowed. */
u16 pf_qos;
u16 tx_rate;
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h
index a5cb755..2963557 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h
@@ -73,6 +73,7 @@ enum ixgbe_pfvf_api_rev {
ixgbe_mbox_api_10, /* API version 1.0, linux/freebsd VF driver */
ixgbe_mbox_api_20, /* API version 2.0, solaris Phase1 VF driver */
ixgbe_mbox_api_11, /* API version 1.1, linux/freebsd VF driver */
+ ixgbe_mbox_api_12, /* API version 1.2, linux/freebsd VF driver */
/* This value should always be last */
ixgbe_mbox_api_unknown, /* indicates that API version is not known */
};
@@ -91,6 +92,9 @@ enum ixgbe_pfvf_api_rev {
/* mailbox API, version 1.1 VF requests */
#define IXGBE_VF_GET_QUEUES 0x09 /* get queue configuration */
+/* mailbox API, version 1.2 VF requests */
+#define IXGBE_VF_SET_MC_PROMISC 0x0a /* VF requests PF to set MC promiscuous */
+
/* GET_QUEUES return data indices within the mailbox */
#define IXGBE_VF_TX_QUEUES 1 /* number of Tx queues supported */
#define IXGBE_VF_RX_QUEUES 2 /* number of Rx queues supported */
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index 01f7081..427993c 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -108,6 +108,10 @@ static int __ixgbe_enable_sriov(struct ixgbe_adapter *adapter)
adapter->flags2 &= ~(IXGBE_FLAG2_RSC_CAPABLE |
IXGBE_FLAG2_RSC_ENABLED);
+ /* Disable multicast promiscuous mode of each VF at first */
+ for (i = 0; i < adapter->num_vfs; i++)
+ adapter->vfinfo[i].vf_mc_promisc = false;
+
/* enable spoof checking for all VFs */
for (i = 0; i < adapter->num_vfs; i++)
adapter->vfinfo[i].spoofchk_enabled = true;
@@ -310,6 +314,46 @@ int ixgbe_pci_sriov_configure(struct pci_dev *dev, int num_vfs)
return ixgbe_pci_sriov_enable(dev, num_vfs);
}
+static int ixgbe_enable_vf_mc_promisc(struct ixgbe_adapter * adapter, u32 vf)
+{
+ struct ixgbe_hw *hw;
+ u32 vmolr;
+
+ if (adapter->vfinfo[vf].vf_mc_promisc)
+ return 0;
+
+ hw = &adapter->hw;
+ vmolr = IXGBE_READ_REG(hw, IXGBE_VMOLR(vf));
+
+ e_info(drv, "VF %u: enabling multicast promiscuous\n", vf);
+
+ vmolr |= IXGBE_VMOLR_MPE;
+
+ IXGBE_WRITE_REG(hw, IXGBE_VMOLR(vf), vmolr);
+
+ return 0;
+}
+
+static int ixgbe_disable_vf_mc_promisc(struct ixgbe_adapter * adapter, u32 vf)
+{
+ struct ixgbe_hw *hw;
+ u32 vmolr;
+
+ if (!adapter->vfinfo[vf].vf_mc_promisc)
+ return 0;
+
+ hw = &adapter->hw;
+ vmolr = IXGBE_READ_REG(hw, IXGBE_VMOLR(vf));
+
+ e_info(drv, "VF %u: disabling multicast promiscuous\n", vf);
+
+ vmolr &= ~IXGBE_VMOLR_MPE;
+
+ IXGBE_WRITE_REG(hw, IXGBE_VMOLR(vf), vmolr);
+
+ return 0;
+}
+
static int ixgbe_set_vf_multicasts(struct ixgbe_adapter *adapter,
u32 *msgbuf, u32 vf)
{
@@ -324,6 +368,9 @@ static int ixgbe_set_vf_multicasts(struct ixgbe_adapter *adapter,
u32 mta_reg;
u32 vmolr = IXGBE_READ_REG(hw, IXGBE_VMOLR(vf));
+ /* Disable multicast promiscuous first */
+ ixgbe_disable_vf_mc_promisc(adapter, vf);
+
/* only so many hash values supported */
entries = min(entries, IXGBE_MAX_VF_MC_ENTRIES);
@@ -426,6 +473,7 @@ static s32 ixgbe_set_vf_lpe(struct ixgbe_adapter *adapter, u32 *msgbuf, u32 vf)
#endif /* CONFIG_FCOE */
switch (adapter->vfinfo[vf].vf_api) {
case ixgbe_mbox_api_11:
+ case ixgbe_mbox_api_12:
/*
* Version 1.1 supports jumbo frames on VFs if PF has
* jumbo frames enabled which means legacy VFs are
@@ -696,6 +744,9 @@ static int ixgbe_vf_reset_msg(struct ixgbe_adapter *adapter, u32 vf)
IXGBE_WRITE_REG(hw, IXGBE_PVFTDWBALn(q_per_pool, vf, i), 0);
}
+ /* Disable multicast promiscuous at reset */
+ ixgbe_disable_vf_mc_promisc(adapter, vf);
+
/* reply to reset with ack and vf mac address */
msgbuf[0] = IXGBE_VF_RESET;
if (!is_zero_ether_addr(vf_mac)) {
@@ -884,6 +935,12 @@ static int ixgbe_negotiate_vf_api(struct ixgbe_adapter *adapter,
switch (api) {
case ixgbe_mbox_api_10:
case ixgbe_mbox_api_11:
+ case ixgbe_mbox_api_12:
+ e_info(drv, "VF %d requested api_version %s\n", vf,
+ (api == ixgbe_mbox_api_12) ? "ixgbe_mbox_api_12" :
+ (api == ixgbe_mbox_api_11) ? "ixgbe_mbox_api_11" :
+ (api == ixgbe_mbox_api_10) ? "ixgbe_mbox_api_10" :
+ "unknown");
adapter->vfinfo[vf].vf_api = api;
return 0;
default:
@@ -907,6 +964,7 @@ static int ixgbe_get_vf_queues(struct ixgbe_adapter *adapter,
switch (adapter->vfinfo[vf].vf_api) {
case ixgbe_mbox_api_20:
case ixgbe_mbox_api_11:
+ case ixgbe_mbox_api_12:
break;
default:
return -1;
@@ -934,6 +992,25 @@ static int ixgbe_get_vf_queues(struct ixgbe_adapter *adapter,
return 0;
}
+static int ixgbe_set_vf_mc_promisc(struct ixgbe_adapter *adapter,
+ u32 *msgbuf, u32 vf)
+{
+ bool enable = !!msgbuf[1]; /* msgbuf contains the flag to enable */
+
+ switch (adapter->vfinfo[vf].vf_api) {
+ case ixgbe_mbox_api_12:
+ break;
+ default:
+ return -1;
+ }
+
+ if (enable)
+ return ixgbe_enable_vf_mc_promisc(adapter, vf);
+ else
+ return ixgbe_disable_vf_mc_promisc(adapter, vf);
+}
+
+
static int ixgbe_rcv_msg_from_vf(struct ixgbe_adapter *adapter, u32 vf)
{
u32 mbx_size = IXGBE_VFMAILBOX_SIZE;
@@ -990,6 +1067,9 @@ static int ixgbe_rcv_msg_from_vf(struct ixgbe_adapter *adapter, u32 vf)
case IXGBE_VF_GET_QUEUES:
retval = ixgbe_get_vf_queues(adapter, msgbuf, vf);
break;
+ case IXGBE_VF_SET_MC_PROMISC:
+ retval = ixgbe_set_vf_mc_promisc(adapter, msgbuf, vf);
+ break;
default:
e_err(drv, "Unhandled Msg %8.8x\n", msgbuf[0]);
retval = IXGBE_ERR_MBX;
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 030a219..3615bdb 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -1635,7 +1635,8 @@ static void ixgbevf_init_last_counter_stats(struct ixgbevf_adapter *adapter)
static void ixgbevf_negotiate_api(struct ixgbevf_adapter *adapter)
{
struct ixgbe_hw *hw = &adapter->hw;
- int api[] = { ixgbe_mbox_api_11,
+ int api[] = { ixgbe_mbox_api_12,
+ ixgbe_mbox_api_11,
ixgbe_mbox_api_10,
ixgbe_mbox_api_unknown };
int err = 0, idx = 0;
@@ -1649,6 +1650,12 @@ static void ixgbevf_negotiate_api(struct ixgbevf_adapter *adapter)
idx++;
}
+ dev_info(&adapter->pdev->dev, "mbox api_version = %s\n",
+ (hw->api_version == ixgbe_mbox_api_12) ? "ixgbe_mbox_api_12" :
+ (hw->api_version == ixgbe_mbox_api_11) ? "ixgbe_mbox_api_11" :
+ (hw->api_version == ixgbe_mbox_api_10) ? "ixgbe_mbox_api_10" :
+ "unknown");
+
spin_unlock_bh(&adapter->mbx_lock);
}
@@ -1827,6 +1834,9 @@ void ixgbevf_down(struct ixgbevf_adapter *adapter)
netif_carrier_off(netdev);
+ /* drop multicast promiscuous mode flag */
+ adapter->hw.mac.mc_promisc = false;
+
if (!pci_channel_offline(adapter->pdev))
ixgbevf_reset(adapter);
@@ -3279,6 +3289,7 @@ static int ixgbevf_change_mtu(struct net_device *netdev, int new_mtu)
switch (adapter->hw.api_version) {
case ixgbe_mbox_api_11:
+ case ixgbe_mbox_api_12:
max_possible_frame = IXGBE_MAX_JUMBO_FRAME_SIZE;
break;
default:
diff --git a/drivers/net/ethernet/intel/ixgbevf/mbx.h b/drivers/net/ethernet/intel/ixgbevf/mbx.h
index 0bc3005..62ef0d8 100644
--- a/drivers/net/ethernet/intel/ixgbevf/mbx.h
+++ b/drivers/net/ethernet/intel/ixgbevf/mbx.h
@@ -86,6 +86,7 @@ enum ixgbe_pfvf_api_rev {
ixgbe_mbox_api_10, /* API version 1.0, linux/freebsd VF driver */
ixgbe_mbox_api_20, /* API version 2.0, solaris Phase1 VF driver */
ixgbe_mbox_api_11, /* API version 1.1, linux/freebsd VF driver */
+ ixgbe_mbox_api_12, /* API version 1.2, linux/freebsd VF driver */
/* This value should always be last */
ixgbe_mbox_api_unknown, /* indicates that API version is not known */
};
@@ -104,6 +105,9 @@ enum ixgbe_pfvf_api_rev {
/* mailbox API, version 1.1 VF requests */
#define IXGBE_VF_GET_QUEUE 0x09 /* get queue configuration */
+/* mailbox API, version 1.2 VF requests */
+#define IXGBE_VF_SET_MC_PROMISC 0x0a /* VF requests PF to set MC promiscuous */
+
/* GET_QUEUES return data indices within the mailbox */
#define IXGBE_VF_TX_QUEUES 1 /* number of Tx queues supported */
#define IXGBE_VF_RX_QUEUES 2 /* number of Rx queues supported */
diff --git a/drivers/net/ethernet/intel/ixgbevf/vf.c b/drivers/net/ethernet/intel/ixgbevf/vf.c
index 9cddd56..43c1ee3 100644
--- a/drivers/net/ethernet/intel/ixgbevf/vf.c
+++ b/drivers/net/ethernet/intel/ixgbevf/vf.c
@@ -120,6 +120,9 @@ static s32 ixgbevf_reset_hw_vf(struct ixgbe_hw *hw)
memcpy(hw->mac.perm_addr, addr, ETH_ALEN);
hw->mac.mc_filter_type = msgbuf[IXGBE_VF_MC_TYPE_WORD];
+ /* after reset, MC promiscuous mode is disabled */
+ hw->mac.mc_promisc = false;
+
return 0;
}
@@ -327,8 +330,29 @@ static s32 ixgbevf_update_mc_addr_list_vf(struct ixgbe_hw *hw,
*/
cnt = netdev_mc_count(netdev);
- if (cnt > 30)
+ if (cnt > 30) {
+ /*
+ * If the API has the capability to handle MC promiscuous
+ * mode, turn it on.
+ */
+ if (hw->api_version == ixgbe_mbox_api_12) {
+ if (!hw->mac.mc_promisc) {
+ struct ixgbevf_adapter *adapter = hw->back;
+
+ dev_info(&adapter->pdev->dev, "Request MC PROMISC\n");
+
+ /* enabling multicast promiscuous */
+ msgbuf[0] = IXGBE_VF_SET_MC_PROMISC;
+ msgbuf[1] = 1;
+ ixgbevf_write_msg_read_ack(hw, msgbuf, 2);
+
+ hw->mac.mc_promisc = true;
+ }
+
+ return 0;
+ }
cnt = 30;
+ }
msgbuf[0] = IXGBE_VF_SET_MULTICAST;
msgbuf[0] |= cnt << IXGBE_VT_MSGINFO_SHIFT;
@@ -344,6 +368,8 @@ static s32 ixgbevf_update_mc_addr_list_vf(struct ixgbe_hw *hw,
ixgbevf_write_msg_read_ack(hw, msgbuf, IXGBE_VFMAILBOX_SIZE);
+ hw->mac.mc_promisc = false;
+
return 0;
}
@@ -545,6 +571,7 @@ int ixgbevf_get_queues(struct ixgbe_hw *hw, unsigned int *num_tcs,
/* do nothing if API doesn't support ixgbevf_get_queues */
switch (hw->api_version) {
case ixgbe_mbox_api_11:
+ case ixgbe_mbox_api_12:
break;
default:
return 0;
diff --git a/drivers/net/ethernet/intel/ixgbevf/vf.h b/drivers/net/ethernet/intel/ixgbevf/vf.h
index aa8cc8d..59d8cf3 100644
--- a/drivers/net/ethernet/intel/ixgbevf/vf.h
+++ b/drivers/net/ethernet/intel/ixgbevf/vf.h
@@ -85,6 +85,7 @@ struct ixgbe_mac_info {
enum ixgbe_mac_type type;
s32 mc_filter_type;
+ bool mc_promisc;
bool get_link_status;
u32 max_tx_queues;
--
1.9.0
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply related
* [patch net-next v4 00/21] introduce rocker switch driver with hardware accelerated datapath api - phase 1: bridge fdb offload
From: Jiri Pirko @ 2014-11-27 10:40 UTC (permalink / raw)
To: netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl, hemal
Hi all.
This patchset is just the first phase of switch and switch-ish device
support api in kernel. Note that the api will extend.
So what this patchset includes:
- introduce switchdev api skeleton for implementing switch drivers
- introduce rocker switch driver which implements switchdev api fdb and
bridge set/get link ndos
As to the discussion if there is need to have specific class of device
representing the switch itself, so far we found no need to introduce that.
But we are generally ok with the idea and when the time comes and it will
be needed, it can be easily introduced without any disturbance.
This patchset introduces switch id export through rtnetlink and sysfs,
which is similar to what we have for port id in SR-IOV. I will send iproute2
patchset for showing the switch id for port netdevs once this is applied.
This applies also for the PF_BRIDGE and fdb iproute2 patches.
iproute2 patches are now available here:
https://github.com/jpirko/iproute2-rocker
For detailed description and version history, please see individual patches.
In v4 I reordered the patches leaving rocker patches on the end of the patchset.
Jiri Pirko (10):
bridge: rename fdb_*_hw to fdb_*_hw_addr to avoid confusion
neigh: sort Neighbor Cache Entry Flags
bridge: convert flags in fbd entry into bitfields
net: make vid as a parameter for ndo_fdb_add/ndo_fdb_del
net: rename netdev_phys_port_id to more generic name
net: introduce generic switch devices support
rtnl: expose physical switch id for particular device
net-sysfs: expose physical switch id for particular device
rocker: introduce rocker switch driver
rocker: implement ndo_fdb_dump
Scott Feldman (9):
bridge: call netdev_sw_port_stp_update when bridge port STP status
changes
bridge: add API to notify bridge driver of learned FBD on offloaded
device
bridge: move private brport flags to if_bridge.h so port drivers can
use flags
bridge: add new brport flag LEARNING_SYNC
bridge: add new hwmode swdev
bridge: add brport flags to dflt bridge_getlink
rocker: implement rocker ofdpa flow table manipulation
rocker: implement L2 bridge offloading
rocker: add ndo_bridge_setlink/getlink support for learning policy
Thomas Graf (2):
rocker: Add proper validation of Netlink attributes
rocker: Use logical operators on booleans
Documentation/ABI/testing/sysfs-class-net | 8 +
Documentation/networking/switchdev.txt | 59 +
MAINTAINERS | 14 +
drivers/net/ethernet/Kconfig | 1 +
drivers/net/ethernet/Makefile | 1 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 2 +-
drivers/net/ethernet/emulex/benet/be_main.c | 3 +-
drivers/net/ethernet/intel/i40e/i40e_main.c | 4 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 6 +-
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 2 +-
drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 11 +-
drivers/net/ethernet/rocker/Kconfig | 27 +
drivers/net/ethernet/rocker/Makefile | 5 +
drivers/net/ethernet/rocker/rocker.c | 4374 ++++++++++++++++++++++
drivers/net/ethernet/rocker/rocker.h | 428 +++
drivers/net/macvlan.c | 4 +-
drivers/net/vxlan.c | 4 +-
include/linux/if_bridge.h | 31 +
include/linux/netdevice.h | 39 +-
include/linux/rtnetlink.h | 9 +-
include/net/switchdev.h | 37 +
include/uapi/linux/if_bridge.h | 1 +
include/uapi/linux/if_link.h | 2 +
include/uapi/linux/neighbour.h | 6 +-
net/Kconfig | 1 +
net/Makefile | 3 +
net/bridge/br_fdb.c | 144 +-
net/bridge/br_private.h | 21 +-
net/bridge/br_stp.c | 7 +
net/core/dev.c | 2 +-
net/core/net-sysfs.c | 26 +-
net/core/rtnetlink.c | 119 +-
net/switchdev/Kconfig | 13 +
net/switchdev/Makefile | 5 +
net/switchdev/switchdev.c | 52 +
35 files changed, 5366 insertions(+), 105 deletions(-)
create mode 100644 Documentation/networking/switchdev.txt
create mode 100644 drivers/net/ethernet/rocker/Kconfig
create mode 100644 drivers/net/ethernet/rocker/Makefile
create mode 100644 drivers/net/ethernet/rocker/rocker.c
create mode 100644 drivers/net/ethernet/rocker/rocker.h
create mode 100644 include/net/switchdev.h
create mode 100644 net/switchdev/Kconfig
create mode 100644 net/switchdev/Makefile
create mode 100644 net/switchdev/switchdev.c
--
1.9.3
^ permalink raw reply
* [patch net-next v4 01/21] bridge: rename fdb_*_hw to fdb_*_hw_addr to avoid confusion
From: Jiri Pirko @ 2014-11-27 10:40 UTC (permalink / raw)
To: netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl, hemal
In-Reply-To: <1417084826-9875-1-git-send-email-jiri@resnulli.us>
The current name might seem that this actually offloads the fdb entry to
hw. So rename it to clearly present that this for hardware address
addition/removal.
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Acked-by: Andy Gospodarek <gospo@cumulusnetworks.com>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
---
v3->v4:
-no change
v2->v3:
-moved the patch to the patchset head
new in v2 as suggested by DaveM
---
net/bridge/br_fdb.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index 6f6c95c..08ef4e7 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -90,7 +90,7 @@ static void fdb_rcu_free(struct rcu_head *head)
* are then updated with the new information.
* Called under RTNL.
*/
-static void fdb_add_hw(struct net_bridge *br, const unsigned char *addr)
+static void fdb_add_hw_addr(struct net_bridge *br, const unsigned char *addr)
{
int err;
struct net_bridge_port *p;
@@ -118,7 +118,7 @@ undo:
* the ports with needed information.
* Called under RTNL.
*/
-static void fdb_del_hw(struct net_bridge *br, const unsigned char *addr)
+static void fdb_del_hw_addr(struct net_bridge *br, const unsigned char *addr)
{
struct net_bridge_port *p;
@@ -133,7 +133,7 @@ static void fdb_del_hw(struct net_bridge *br, const unsigned char *addr)
static void fdb_delete(struct net_bridge *br, struct net_bridge_fdb_entry *f)
{
if (f->is_static)
- fdb_del_hw(br, f->addr.addr);
+ fdb_del_hw_addr(br, f->addr.addr);
hlist_del_rcu(&f->hlist);
fdb_notify(br, f, RTM_DELNEIGH);
@@ -514,7 +514,7 @@ static int fdb_insert(struct net_bridge *br, struct net_bridge_port *source,
return -ENOMEM;
fdb->is_local = fdb->is_static = 1;
- fdb_add_hw(br, addr);
+ fdb_add_hw_addr(br, addr);
fdb_notify(br, fdb, RTM_NEWNEIGH);
return 0;
}
@@ -754,19 +754,19 @@ static int fdb_add_entry(struct net_bridge_port *source, const __u8 *addr,
fdb->is_local = 1;
if (!fdb->is_static) {
fdb->is_static = 1;
- fdb_add_hw(br, addr);
+ fdb_add_hw_addr(br, addr);
}
} else if (state & NUD_NOARP) {
fdb->is_local = 0;
if (!fdb->is_static) {
fdb->is_static = 1;
- fdb_add_hw(br, addr);
+ fdb_add_hw_addr(br, addr);
}
} else {
fdb->is_local = 0;
if (fdb->is_static) {
fdb->is_static = 0;
- fdb_del_hw(br, addr);
+ fdb_del_hw_addr(br, addr);
}
}
--
1.9.3
^ permalink raw reply related
* [patch net-next v4 02/21] neigh: sort Neighbor Cache Entry Flags
From: Jiri Pirko @ 2014-11-27 10:40 UTC (permalink / raw)
To: netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl, hemal
In-Reply-To: <1417084826-9875-1-git-send-email-jiri@resnulli.us>
Suggested-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
new in v4
---
include/uapi/linux/neighbour.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/include/uapi/linux/neighbour.h b/include/uapi/linux/neighbour.h
index 4a1d7e9..2f043af 100644
--- a/include/uapi/linux/neighbour.h
+++ b/include/uapi/linux/neighbour.h
@@ -35,11 +35,10 @@ enum {
*/
#define NTF_USE 0x01
-#define NTF_PROXY 0x08 /* == ATF_PUBL */
-#define NTF_ROUTER 0x80
-
#define NTF_SELF 0x02
#define NTF_MASTER 0x04
+#define NTF_PROXY 0x08 /* == ATF_PUBL */
+#define NTF_ROUTER 0x80
/*
* Neighbor Cache Entry States.
--
1.9.3
^ permalink raw reply related
* [patch net-next v4 03/21] bridge: convert flags in fbd entry into bitfields
From: Jiri Pirko @ 2014-11-27 10:40 UTC (permalink / raw)
To: netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl, hemal
In-Reply-To: <1417084826-9875-1-git-send-email-jiri@resnulli.us>
Suggested-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
new in v4
---
net/bridge/br_private.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 8f3f081..5b37077 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -98,9 +98,9 @@ struct net_bridge_fdb_entry
unsigned long updated;
unsigned long used;
mac_addr addr;
- unsigned char is_local;
- unsigned char is_static;
- unsigned char added_by_user;
+ unsigned char is_local:1,
+ is_static:1,
+ added_by_user:1;
__u16 vlan_id;
};
--
1.9.3
^ permalink raw reply related
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