* Re: [RFC 02/10] IB/hfi-vnic: Virtual Network Interface Controller (VNIC) Bus driver
From: Vishwanathapura, Niranjana @ 2016-11-22 1:53 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Dennis Dalessandro
In-Reply-To: <20161121233118.GA31132-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
On Mon, Nov 21, 2016 at 04:31:18PM -0700, Jason Gunthorpe wrote:
>> >>>>+ ida_init(&hfi_vnic_ctrl_ida);
>> >>>>+ idr_init(&hfi_vnic_idr);
>> >>>>+
>> >>>>+ rc = bus_register(&hfi_vnic_bus);
>> >>>
>> >>>Why on earth do we need this? Didn't I give you enough grief for the
>> >>>psm stuff and now you want to create an entire subystem hidden away!?
>> >>>
>> >>>Use some netlink scheme to control your vnic like the rest of the net
>> >>>stack..
>> >>>
>> >>
>> >>The hfi_vnic_bus is only abstracting the HW independent functionality (like
>> >>Ethernet interface, encapsulation, IB MAD interface etc) with the HW
>> >>dependent functionality (sending/receiving packets on the wire).
>> >>Thus providing a cleaner interface between HW independent hfi_vnic Ethernet
>> >>and Control drivers and the HW dependent HFI1 driver.
>> >
>> >That doesn't explain anything, sound like you don't need it so get rid
>> >of it.
>
>> >>There is no other User interface here other than the standard Ethernet
>> >>interface through network stack.
>> >
>> >Good, then this isn't needed, because it doesn't provide a user interface.
>> >
>>
>> Can you explain what exactly you are asking to get rid of here and why?
>
>Get rid of the bus_register/etc as drivers do not get to call this.
>
There are many example drivers in kernel which are using bus_register() in
an initcall.
We could add a custom Interface between HFI1 driver and hfi_vnic drivers
without involving a bus.
But using the existing bus model gave a lot of in-built flexibility in
decoupling devices from the drivers.
Niranjana
>Jason
--
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
* [PATCH net 1/1] driver: macvlan: Check if need rollback multicast setting in macvlan_open
From: fgao @ 2016-11-22 1:54 UTC (permalink / raw)
To: davem, kaber, netdev, gfree.wind; +Cc: Gao Feng
From: Gao Feng <fgao@ikuai8.com>
When dev_set_promiscuity failed in macvlan_open, it always invokes
dev_set_allmulti without checking if necessary.
Now check the IFF_ALLMULTI flag firstly before rollback the multicast
setting in the error handler.
Signed-off-by: Gao Feng <fgao@ikuai8.com>
---
drivers/net/macvlan.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index d2d6f12..26d6f0b 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -623,7 +623,8 @@ static int macvlan_open(struct net_device *dev)
return 0;
clear_multi:
- dev_set_allmulti(lowerdev, -1);
+ if (dev->flags & IFF_ALLMULTI)
+ dev_set_allmulti(lowerdev, -1);
del_unicast:
dev_uc_del(lowerdev, dev->dev_addr);
out:
--
1.9.1
^ permalink raw reply related
* [PATCH] netdevice.h: fix kernel-doc warning
From: Randy Dunlap @ 2016-11-22 2:28 UTC (permalink / raw)
To: netdev@vger.kernel.org, David Miller
From: Randy Dunlap <rdunlap@infradead.org>
Fix kernel-doc warning in <linux/netdevice.h> (missing ':'):
..//include/linux/netdevice.h:1904: warning: No description found for parameter 'prio_tc_map[TC_BITMASK + 1]'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---
include/linux/netdevice.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- lnx-49-rc6.orig/include/linux/netdevice.h
+++ lnx-49-rc6/include/linux/netdevice.h
@@ -1619,7 +1619,7 @@ enum netdev_priv_flags {
* @dcbnl_ops: Data Center Bridging netlink ops
* @num_tc: Number of traffic classes in the net device
* @tc_to_txq: XXX: need comments on this one
- * @prio_tc_map XXX: need comments on this one
+ * @prio_tc_map: XXX: need comments on this one
*
* @fcoe_ddp_xid: Max exchange id for FCoE LRO by ddp
*
^ permalink raw reply
* Re: [PATCH] net: ioctl SIOCSIFADDR minor cleanup
From: Cong Wang @ 2016-11-22 4:20 UTC (permalink / raw)
To: YUAN Linyu; +Cc: David Miller, cugyly@163.com, netdev@vger.kernel.org
In-Reply-To: <8729016553E3654398EA69218DA29EEF0E42F7ED@cnshjmbx02>
On Tue, Nov 15, 2016 at 7:57 PM, YUAN Linyu
<Linyu.Yuan@alcatel-sbell.com.cn> wrote:
> No, this patch will not change dev->name,
> It's care about ifa->ifa_label.
>> - if (colon)
>> - memcpy(ifa->ifa_label, ifr.ifr_name, IFNAMSIZ);
>> - else
>> - memcpy(ifa->ifa_label, dev->name, IFNAMSIZ);
> When ifr.ifr_name have no colon, dev->name must equal to ifr.ifr_name.
> So we change to
>> - else
>> - memcpy(ifa->ifa_label, ifr.ifr_name, IFNAMSIZ);
> Then if and else do same thing. Just one line is enough,
> memcpy(ifa->ifa_label, ifr.ifr_name, IFNAMSIZ);
>
I don't understand why you try to optimize a slow path and some kind of
obsolete code.
^ permalink raw reply
* RE: [PATCH] net: ioctl SIOCSIFADDR minor cleanup
From: YUAN Linyu @ 2016-11-22 4:30 UTC (permalink / raw)
To: Cong Wang; +Cc: David Miller, cugyly@163.com, netdev@vger.kernel.org
In-Reply-To: <CAM_iQpW0SnpXfN-DjBm-72_23KxtzH8kXbbc3FiQn=VChdX3Ww@mail.gmail.com>
I think there are newbie include me still use ifconfig utility.
So when I check this code, it can be optimized.
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Cong Wang
> Sent: Tuesday, November 22, 2016 12:20 PM
> To: YUAN Linyu
> Cc: David Miller; cugyly@163.com; netdev@vger.kernel.org
> Subject: Re: [PATCH] net: ioctl SIOCSIFADDR minor cleanup
>
> On Tue, Nov 15, 2016 at 7:57 PM, YUAN Linyu
> <Linyu.Yuan@alcatel-sbell.com.cn> wrote:
> > No, this patch will not change dev->name,
> > It's care about ifa->ifa_label.
> >> - if (colon)
> >> - memcpy(ifa->ifa_label, ifr.ifr_name,
> IFNAMSIZ);
> >> - else
> >> - memcpy(ifa->ifa_label, dev->name,
> IFNAMSIZ);
> > When ifr.ifr_name have no colon, dev->name must equal to ifr.ifr_name.
> > So we change to
> >> - else
> >> - memcpy(ifa->ifa_label, ifr.ifr_name,
> IFNAMSIZ);
> > Then if and else do same thing. Just one line is enough,
> > memcpy(ifa->ifa_label, ifr.ifr_name, IFNAMSIZ);
> >
>
> I don't understand why you try to optimize a slow path and some kind of
> obsolete code.
^ permalink raw reply
* Re: [RFC PATCH net v2 1/3] net: phy: add an option to disable EEE advertisement
From: Anand Moon @ 2016-11-22 5:04 UTC (permalink / raw)
To: Jerome Brunet
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree, Florian Fainelli,
Alexandre TORGUE, Neil Armstrong, Martin Blumenstingl,
Kevin Hilman, Linux Kernel, Andre Roth,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Carlo Caione,
Giuseppe Cavallaro, linux-arm-kernel
In-Reply-To: <1479742524-30222-2-git-send-email-jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Hi Jerome,
On 21 November 2016 at 21:05, Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote:
> This patch adds an option to disable EEE advertisement in the generic PHY
> by providing a mask of prohibited modes corresponding to the value found in
> the MDIO_AN_EEE_ADV register.
>
> On some platforms, PHY Low power idle seems to be causing issues, even
> breaking the link some cases. The patch provides a convenient way for these
> platforms to disable EEE advertisement and work around the issue.
>
> Signed-off-by: Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> drivers/net/phy/phy.c | 3 ++
> drivers/net/phy/phy_device.c | 80 +++++++++++++++++++++++++++++++++++++++-----
> include/linux/phy.h | 3 ++
> 3 files changed, 77 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> index f424b867f73e..a44ee14bd953 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -1348,6 +1348,9 @@ int phy_ethtool_set_eee(struct phy_device *phydev, struct ethtool_eee *data)
> {
> int val = ethtool_adv_to_mmd_eee_adv_t(data->advertised);
>
> + /* Mask prohibited EEE modes */
> + val &= ~phydev->eee_advert_disabled;
> +
> phy_write_mmd_indirect(phydev, MDIO_AN_EEE_ADV, MDIO_MMD_AN, val);
>
> return 0;
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 1a4bf8acad78..74c628e046cb 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -1116,6 +1116,43 @@ static int genphy_config_advert(struct phy_device *phydev)
> }
>
> /**
> + * genphy_config_eee_advert - disable unwanted eee mode advertisement
> + * @phydev: target phy_device struct
> + *
> + * Description: Writes MDIO_AN_EEE_ADV after disabling unsupported energy
> + * efficent ethernet modes. Returns 0 if the PHY's advertisement hasn't
> + * changed, and 1 if it has changed.
> + */
> +static int genphy_config_eee_advert(struct phy_device *phydev)
> +{
> + u32 disabled = phydev->eee_advert_disabled;
> + u32 old_adv, adv;
> +
> + /* Nothing to disable */
> + if (!disabled)
> + return 0;
> +
> + /* If the following call fails, we assume that EEE is not
> + * supported by the phy. If we read 0, EEE is not advertised
> + * In both case, we don't need to continue
> + */
> + adv = phy_read_mmd_indirect(phydev, MDIO_AN_EEE_ADV, MDIO_MMD_AN);
> + if (adv <= 0)
> + return 0;
> +
> + old_adv = adv;
> + adv &= ~disabled;
> +
> + /* Advertising remains unchanged with the ban */
> + if (old_adv == adv)
> + return 0;
> +
> + phy_write_mmd_indirect(phydev, MDIO_AN_EEE_ADV, MDIO_MMD_AN, adv);
> +
> + return 1;
> +}
> +
> +/**
> * genphy_setup_forced - configures/forces speed/duplex from @phydev
> * @phydev: target phy_device struct
> *
> @@ -1173,15 +1210,20 @@ EXPORT_SYMBOL(genphy_restart_aneg);
> */
> int genphy_config_aneg(struct phy_device *phydev)
> {
> - int result;
> + int err, changed;
> +
> + changed = genphy_config_eee_advert(phydev);
>
> if (AUTONEG_ENABLE != phydev->autoneg)
> return genphy_setup_forced(phydev);
>
> - result = genphy_config_advert(phydev);
> - if (result < 0) /* error */
> - return result;
> - if (result == 0) {
> + err = genphy_config_advert(phydev);
> + if (err < 0) /* error */
> + return err;
> +
> + changed |= err;
> +
> + if (changed == 0) {
> /* Advertisement hasn't changed, but maybe aneg was never on to
> * begin with? Or maybe phy was isolated?
> */
> @@ -1191,16 +1233,16 @@ int genphy_config_aneg(struct phy_device *phydev)
> return ctl;
>
> if (!(ctl & BMCR_ANENABLE) || (ctl & BMCR_ISOLATE))
> - result = 1; /* do restart aneg */
> + changed = 1; /* do restart aneg */
> }
>
> /* Only restart aneg if we are advertising something different
> * than we were before.
> */
> - if (result > 0)
> - result = genphy_restart_aneg(phydev);
> + if (changed > 0)
> + return genphy_restart_aneg(phydev);
>
> - return result;
> + return 0;
> }
> EXPORT_SYMBOL(genphy_config_aneg);
>
> @@ -1558,6 +1600,21 @@ static void of_set_phy_supported(struct phy_device *phydev)
> __set_phy_supported(phydev, max_speed);
> }
>
> +static void of_set_phy_eee_disable(struct phy_device *phydev)
> +{
> + struct device_node *node = phydev->mdio.dev.of_node;
> + u32 disabled;
> +
> + if (!IS_ENABLED(CONFIG_OF_MDIO))
> + return;
> +
> + if (!node)
> + return;
> +
> + if (!of_property_read_u32(node, "eee-advert-disable", &disabled))
> + phydev->eee_advert_disabled = disabled;
> +}
> +
> /**
> * phy_probe - probe and init a PHY device
> * @dev: device to probe and init
> @@ -1595,6 +1652,11 @@ static int phy_probe(struct device *dev)
> of_set_phy_supported(phydev);
> phydev->advertising = phydev->supported;
>
> + /* Get the EEE modes we want to prohibit. We will ask
> + * the PHY stop advertising these mode later on
> + */
> + of_set_phy_eee_disable(phydev);
> +
> /* Set the state to READY by default */
> phydev->state = PHY_READY;
>
> diff --git a/include/linux/phy.h b/include/linux/phy.h
> index e25f1830fbcf..7f2ea0af16d1 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -401,6 +401,9 @@ struct phy_device {
> u32 advertising;
> u32 lp_advertising;
>
> + /* Energy efficient ethernet modes which should be prohibited */
> + u32 eee_advert_disabled;
> +
> int autoneg;
>
> int link_timeout;
> --
> 2.7.4
>
iperf3 tcp test summary at my end
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-100.00 sec 10.9 GBytes 936 Mbits/sec 0 sender
[ 4] 0.00-100.00 sec 10.9 GBytes 936 Mbits/sec receiver
CPU Utilization: local/sender 5.7% (0.2%u/5.5%s), remote/receiver
11.9% (0.9%u/11.0%s)
iperf3 udp test summary at my end.
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Jitter
Lost/Total Datagrams
[ 4] 0.00-100.00 sec 12.5 MBytes 1.05 Mbits/sec 0.025 ms 0/1599 (0%)
[ 4] Sent 1599 datagrams
CPU Utilization: local/sender 0.1% (0.0%u/0.1%s), remote/receiver 0.0%
(0.0%u/0.0%s)
Best Regards
-Anand Moon
>
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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
* [PATCH] bnxt_en: Fix a VXLAN vs GENEVE issue
From: Christophe JAILLET @ 2016-11-22 5:14 UTC (permalink / raw)
To: davem, michael.chan, prashant.sreedharan
Cc: netdev, kernel-janitors, Christophe JAILLET
Knowing that:
#define TUNNEL_DST_PORT_FREE_REQ_TUNNEL_TYPE_VXLAN (0x1UL << 0)
#define TUNNEL_DST_PORT_FREE_REQ_TUNNEL_TYPE_GENEVE (0x5UL << 0)
and that 'bnxt_hwrm_tunnel_dst_port_alloc()' is only called with one of
these 2 constants, the TUNNEL_DST_PORT_ALLOC_REQ_TUNNEL_TYPE_GENEVE can not
trigger.
Replace the bit test that overlap by an equality test, just as in
'bnxt_hwrm_tunnel_dst_port_free()' above.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
Compile-tested only
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index d313b02485a1..25d9ffe51825 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -3210,11 +3210,17 @@ static int bnxt_hwrm_tunnel_dst_port_alloc(struct bnxt *bp, __be16 port,
goto err_out;
}
- if (tunnel_type & TUNNEL_DST_PORT_ALLOC_REQ_TUNNEL_TYPE_VXLAN)
+ switch (tunnel_type) {
+ case TUNNEL_DST_PORT_ALLOC_REQ_TUNNEL_TYPE_VXLAN:
bp->vxlan_fw_dst_port_id = resp->tunnel_dst_port_id;
-
- else if (tunnel_type & TUNNEL_DST_PORT_ALLOC_REQ_TUNNEL_TYPE_GENEVE)
+ break;
+ case TUNNEL_DST_PORT_ALLOC_REQ_TUNNEL_TYPE_GENEVE:
bp->nge_fw_dst_port_id = resp->tunnel_dst_port_id;
+ break;
+ default:
+ break;
+ }
+
err_out:
mutex_unlock(&bp->hwrm_cmd_lock);
return rc;
--
2.9.3
^ permalink raw reply related
* Re: [PATCH net 1/1] net sched filters: pass netlink message flags in event notification
From: Cong Wang @ 2016-11-22 5:23 UTC (permalink / raw)
To: Roman Mashak
Cc: David Miller, Linux Kernel Network Developers, Jamal Hadi Salim
In-Reply-To: <CAM_iQpU_ivg4eBV=88DH6qEcomrq0+G5M=c9rafLszf09PAP_w@mail.gmail.com>
On Thu, Nov 17, 2016 at 1:02 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Wed, Nov 16, 2016 at 2:16 PM, Roman Mashak <mrv@mojatatu.com> wrote:
>> Userland client should be able to read an event, and reflect it back to
>> the kernel, therefore it needs to extract complete set of netlink flags.
>>
>> For example, this will allow "tc monitor" to distinguish Add and Replace
>> operations.
>>
>> Signed-off-by: Roman Mashak <mrv@mojatatu.com>
>> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
>> ---
>> net/sched/cls_api.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
>> index 2b2a797..8e93d4a 100644
>> --- a/net/sched/cls_api.c
>> +++ b/net/sched/cls_api.c
>> @@ -112,7 +112,7 @@ static void tfilter_notify_chain(struct net *net, struct sk_buff *oskb,
>>
>> for (it_chain = chain; (tp = rtnl_dereference(*it_chain)) != NULL;
>> it_chain = &tp->next)
>> - tfilter_notify(net, oskb, n, tp, 0, event, false);
>> + tfilter_notify(net, oskb, n, tp, n->nlmsg_flags, event, false);
>
>
> I must miss something, why does it make sense to pass n->nlmsg_flags
> as 'fh' to tfilter_notify()??
Ping... Any response?
It still doesn't look correct to me. I will send a fix unless someone could
explain this.
^ permalink raw reply
* Re: [PATCH net 1/1] net: l2tp: Treat NET_XMIT_CN as success in l2tp_eth_dev_xmit
From: Cong Wang @ 2016-11-22 5:29 UTC (permalink / raw)
To: fgao
Cc: Eric Dumazet, David Miller, javier,
Linux Kernel Network Developers, Feng Gao
In-Reply-To: <1479689781-2125-1-git-send-email-fgao@ikuai8.com>
On Sun, Nov 20, 2016 at 4:56 PM, <fgao@ikuai8.com> wrote:
> From: Gao Feng <gfree.wind@gmail.com>
>
> The tc could return NET_XMIT_CN as one congestion notification, but
> it does not mean the packe is lost. Other modules like ipvlan,
> macvlan, and others treat NET_XMIT_CN as success too.
> So l2tp_eth_dev_xmit should add the NET_XMIT_CN check.
>
> Signed-off-by: Gao Feng <gfree.wind@gmail.com>
> ---
> net/l2tp/l2tp_eth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/l2tp/l2tp_eth.c b/net/l2tp/l2tp_eth.c
> index 965f7e3..3dc97b4 100644
> --- a/net/l2tp/l2tp_eth.c
> +++ b/net/l2tp/l2tp_eth.c
> @@ -97,7 +97,7 @@ static int l2tp_eth_dev_xmit(struct sk_buff *skb, struct net_device *dev)
> unsigned int len = skb->len;
> int ret = l2tp_xmit_skb(session, skb, session->hdr_len);
>
> - if (likely(ret == NET_XMIT_SUCCESS)) {
> + if (likely(ret == NET_XMIT_SUCCESS || ret == NET_XMIT_CN)) {
How could l2tp_xmit_skb() possibly return NET_XMIT_CN?
Note It ignores the return value of l2tp_xmit_core().
^ permalink raw reply
* Re: [RFC PATCH net v2 2/3] dt: bindings: add ethernet phy eee-disable-advert option documentation
From: Florian Fainelli @ 2016-11-22 5:35 UTC (permalink / raw)
To: Andrew Lunn, Jerome Brunet
Cc: netdev, devicetree, Alexandre TORGUE, Neil Armstrong,
Martin Blumenstingl, Kevin Hilman, linux-kernel, Andre Roth,
linux-amlogic, Carlo Caione, Giuseppe Cavallaro, linux-arm-kernel
In-Reply-To: <20161121164733.GG1922@lunn.ch>
Le 21/11/2016 à 08:47, Andrew Lunn a écrit :
>> What I did not realize when doing this patch for the realtek driver is
>> that there is already 6 valid modes defined in the kernel
>>
>> #define MDIO_EEE_100TX MDIO_AN_EEE_ADV_100TX /*
>> 100TX EEE cap */
>> #define MDIO_EEE_1000T MDIO_AN_EEE_ADV_1000T /*
>> 1000T EEE cap */
>> #define MDIO_EEE_10GT 0x0008 /* 10GT EEE cap */
>> #define MDIO_EEE_1000KX 0x0010 /* 1000KX EEE cap
>> */
>> #define MDIO_EEE_10GKX4 0x0020 /* 10G KX4 EEE cap
>> */
>> #define MDIO_EEE_10GKR 0x0040 /* 10G KR EEE cap
>> */
>>
>> I took care of only 2 in the case of realtek.c since it only support
>> MDIO_EEE_100TX and MDIO_EEE_1000T.
>>
>> Defining a property for each is certainly doable but it does not look
>> very nice either. If it extends in the future, it will get even more
>> messier, especially if you want to disable everything.
>
> Yes, agreed.
One risk with the definition a group of advertisement capabilities
(under the form of a bitmask for instance) to enable/disable is that we
end up with Device Tree contain some kind of configuration policy as
opposed to just flagging particular hardware features as broken.
Fortunately, there does not seem to be a ton of PHYs out there which
require EEE to be disabled to function properly so having individual
properties vs. bitmasks/groups is kind of speculative here.
Another approach to solving this problem could be to register a PHY
fixup which disables EEE at the PHY level, and which is only called for
specific boards affected by this problem (of_machine_is_compatible()).
This code can leave in arch/*/* when that is possible, or it can just be
somewhere where it is relevant, e.g; in the PHY driver for instance
(similarly to how PCI fixups are done).
--
Florian
^ permalink raw reply
* [PATCH] mac80211: Remove unused 'struct ieee80211_rx_status' ptr
From: Kirtika Ruchandani @ 2016-11-22 5:44 UTC (permalink / raw)
To: Johannes Berg
Cc: Arnd Bergmann, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
Commit 554891e63a29 introduced 'struct ieee80211_rx_status' in
ieee80211_rx_h_defragment but did not use it. Compiling with W=1
gives the following warning, fix it.
net/mac80211/rx.c: In function ‘ieee80211_rx_h_defragment’:
net/mac80211/rx.c:1911:30: warning: variable ‘status’ set but not used [-Wunused-but-set-variable]
Fixes: 554891e63a29 ("mac80211: move packet flags into packet")
Cc: Johannes Berg <johannes.berg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: John W. Linville <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Signed-off-by: Kirtika Ruchandani <kirtika-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
---
net/mac80211/rx.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index eeab725..d2a00f2 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1908,7 +1908,6 @@ ieee80211_rx_h_defragment(struct ieee80211_rx_data *rx)
unsigned int frag, seq;
struct ieee80211_fragment_entry *entry;
struct sk_buff *skb;
- struct ieee80211_rx_status *status;
hdr = (struct ieee80211_hdr *)rx->skb->data;
fc = hdr->frame_control;
@@ -2034,9 +2033,6 @@ ieee80211_rx_h_defragment(struct ieee80211_rx_data *rx)
dev_kfree_skb(skb);
}
- /* Complete frame has been reassembled - process it now */
- status = IEEE80211_SKB_RXCB(rx->skb);
^ permalink raw reply related
* [PATCH] mac80211: Remove unused 'rates_idx' variable
From: Kirtika Ruchandani @ 2016-11-22 6:04 UTC (permalink / raw)
To: Johannes Berg
Cc: Arnd Bergmann, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Felix Fietkau, Johannes Berg
Commit f027c2aca0cf introduced 'rates_idx' in
ieee80211_tx_status_noskb but did not use it. Compiling with W=1
gives the following warning, fix it.
mac80211/status.c: In function ‘ieee80211_tx_status_noskb’:
mac80211/status.c:636:6: warning: variable ‘rates_idx’ set but not used [-Wunused-but-set-variable]
This is a harmless warning, and is only being fixed to reduce the
noise generated with W=1.
Fixes: f027c2aca0cf ("mac80211: add ieee80211_tx_status_noskb")
Cc: Johannes Berg <johannes.berg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: Felix Fietkau <nbd-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
Signed-off-by: Kirtika Ruchandani <kirtika-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
---
net/mac80211/status.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index ddf71c6..f7c5ae5 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -633,10 +633,9 @@ void ieee80211_tx_status_noskb(struct ieee80211_hw *hw,
struct ieee80211_local *local = hw_to_local(hw);
struct ieee80211_supported_band *sband;
int retry_count;
- int rates_idx;
bool acked, noack_success;
- rates_idx = ieee80211_tx_get_rates(hw, info, &retry_count);
+ ieee80211_tx_get_rates(hw, info, &retry_count);
sband = hw->wiphy->bands[info->band];
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [net] rtnetlink: fix the wrong minimal dump size getting from rtnl_calcit()
From: Zhang Shengju @ 2016-11-22 6:14 UTC (permalink / raw)
To: netdev, davem; +Cc: roopa
For RT netlink, calcit() function should return the minimal size for
netlink dump message. This will make sure that dump message for every
network device can be stored.
Currently, rtnl_calcit() function doesn't account the size of header of
netlink message, this patch will fix it.
Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
---
net/core/rtnetlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index f4b9350..09e115b 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -2734,7 +2734,7 @@ static u16 rtnl_calcit(struct sk_buff *skb, struct nlmsghdr *nlh)
ext_filter_mask));
}
- return min_ifinfo_dump_size;
+ return nlmsg_total_size(min_ifinfo_dump_size);
}
static int rtnl_dump_all(struct sk_buff *skb, struct netlink_callback *cb)
--
1.8.3.1
^ permalink raw reply related
* [PATCH] ipv6:ipv6_pinfo dereferenced after NULL check
From: Manjeet Pawar @ 2016-11-22 6:27 UTC (permalink / raw)
To: davem, kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
Cc: pankaj.m, ajeet.y, Rohit Thapliyal, Manjeet Pawar
From: Rohit Thapliyal <r.thapliyal@samsung.com>
np checked for NULL and then dereferenced. It should be modified
for NULL case.
Signed-off-by: Rohit Thapliyal <r.thapliyal@samsung.com>
Signed-off-by: Manjeet Pawar <manjeet.p@samsung.com>
---
net/ipv6/ip6_output.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 1dfc402..c2afa14 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -205,14 +205,15 @@ int ip6_xmit(const struct sock *sk, struct sk_buff *skb, struct flowi6 *fl6,
/*
* Fill in the IPv6 header
*/
- if (np)
+ if (np) {
hlimit = np->hop_limit;
+ ip6_flow_hdr(
+ hdr, tclass, ip6_make_flowlabel(
+ net, skb, fl6->flowlabel,
+ np->autoflowlabel, fl6));
+ }
if (hlimit < 0)
hlimit = ip6_dst_hoplimit(dst);
- ip6_flow_hdr(hdr, tclass, ip6_make_flowlabel(net, skb, fl6->flowlabel,
- np->autoflowlabel, fl6));
-
hdr->payload_len = htons(seg_len);
hdr->nexthdr = proto;
hdr->hop_limit = hlimit;
--
1.9.1
^ permalink raw reply related
* Re: [mm PATCH v3 21/23] mm: Add support for releasing multiple instances of a page
From: Andrew Morton @ 2016-11-22 6:28 UTC (permalink / raw)
To: Alexander Duyck
Cc: Alexander Duyck, linux-mm, Netdev, linux-kernel@vger.kernel.org
In-Reply-To: <CAKgT0UfoS-JC66hHV14E-hgmrhGdz4oYpmHve=01A1X8o8O=rw@mail.gmail.com>
On Mon, 21 Nov 2016 08:21:39 -0800 Alexander Duyck <alexander.duyck@gmail.com> wrote:
> >> + __free_pages_ok(page, order);
> >> + }
> >> +}
> >> +EXPORT_SYMBOL(__page_frag_drain);
> >
> > It's an exported-to-modules library function. It should be documented,
> > please? The page-frag API is only partially documented, but that's no
> > excuse.
>
> Okay. I assume you want the documentation as a follow-up patch since
> I received a notice that the patch was added to -mm?
Yes please. Or a replacement patch which I'll temporarily turn into a
delta, either is fine.
> If you would like I could look at doing a couple of renaming patches
> so that we make the API a bit more consistent. I could move the
> __alloc and __free to what you have suggested, and then take a look at
> trying to rename the refill/drain to be a bit more consistent in terms
> of what they are supposed to work on and how they are supposed to be
> used.
I think that would be better - it's hardly high-priority but a bit of
attention to the documentation and naming conventions would help tidy
things up. When you can't find anything else to do ;)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH net 1/1] net: l2tp: Treat NET_XMIT_CN as success in l2tp_eth_dev_xmit
From: Gao Feng @ 2016-11-22 6:32 UTC (permalink / raw)
To: Cong Wang
Cc: Eric Dumazet, David Miller, javier,
Linux Kernel Network Developers
In-Reply-To: <CAM_iQpX-z8Eja4rPg5dzAXLXd6v3nwMMPev-gk+wM9XLBNYK1A@mail.gmail.com>
Hi Cong,
On Tue, Nov 22, 2016 at 1:29 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Sun, Nov 20, 2016 at 4:56 PM, <fgao@ikuai8.com> wrote:
>> From: Gao Feng <gfree.wind@gmail.com>
>>
>> The tc could return NET_XMIT_CN as one congestion notification, but
>> it does not mean the packe is lost. Other modules like ipvlan,
>> macvlan, and others treat NET_XMIT_CN as success too.
>> So l2tp_eth_dev_xmit should add the NET_XMIT_CN check.
>>
>> Signed-off-by: Gao Feng <gfree.wind@gmail.com>
>> ---
>> net/l2tp/l2tp_eth.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/l2tp/l2tp_eth.c b/net/l2tp/l2tp_eth.c
>> index 965f7e3..3dc97b4 100644
>> --- a/net/l2tp/l2tp_eth.c
>> +++ b/net/l2tp/l2tp_eth.c
>> @@ -97,7 +97,7 @@ static int l2tp_eth_dev_xmit(struct sk_buff *skb, struct net_device *dev)
>> unsigned int len = skb->len;
>> int ret = l2tp_xmit_skb(session, skb, session->hdr_len);
>>
>> - if (likely(ret == NET_XMIT_SUCCESS)) {
>> + if (likely(ret == NET_XMIT_SUCCESS || ret == NET_XMIT_CN)) {
>
> How could l2tp_xmit_skb() possibly return NET_XMIT_CN?
> Note It ignores the return value of l2tp_xmit_core().
You are right. I didn't think about it.
Regards
Feng
^ permalink raw reply
* [PATCH] mac80211: Remove unused 'struct rate_control_ref' variable
From: Kirtika Ruchandani @ 2016-11-22 6:54 UTC (permalink / raw)
To: Johannes Berg
Cc: Arnd Bergmann, linux-wireless, netdev, Maxim Altshul,
Johannes Berg
Commit 3b17fbf87d5d introduced sta_get_expected_throughput()
leaving variable 'struct rate_control_ref* ref' set but unused.
Compiling with W=1 gives the following warning, fix it.
net/mac80211/sta_info.c: In function ‘sta_set_sinfo’:
net/mac80211/sta_info.c:2052:27: warning: variable ‘ref’ set but not used [-Wunused-but-set-variable]
Fixes: 3b17fbf87d5d ("mac80211: mesh: Add support for HW RC implementation")
Cc: Johannes Berg <johannes.berg@intel.com>
Cc: Maxim Altshul <maxim.altshul@ti.com>
Signed-off-by: Kirtika Ruchandani <kirtika@google.com>
---
net/mac80211/sta_info.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 1711bae..4ab75a9 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -2049,16 +2049,12 @@ void sta_set_sinfo(struct sta_info *sta, struct station_info *sinfo)
{
struct ieee80211_sub_if_data *sdata = sta->sdata;
struct ieee80211_local *local = sdata->local;
- struct rate_control_ref *ref = NULL;
u32 thr = 0;
int i, ac, cpu;
struct ieee80211_sta_rx_stats *last_rxstats;
last_rxstats = sta_get_last_rx_stats(sta);
- if (test_sta_flag(sta, WLAN_STA_RATE_CONTROL))
- ref = local->rate_ctrl;
-
sinfo->generation = sdata->local->sta_generation;
/* do before driver, so beacon filtering drivers have a
^ permalink raw reply related
* Re: [PATCH] bnxt_en: Fix a VXLAN vs GENEVE issue
From: Michael Chan @ 2016-11-22 7:15 UTC (permalink / raw)
To: Christophe JAILLET
Cc: David Miller, Prashant Sreedharan, Netdev, kernel-janitors
In-Reply-To: <20161122051440.9748-1-christophe.jaillet@wanadoo.fr>
On Mon, Nov 21, 2016 at 9:14 PM, Christophe JAILLET
<christophe.jaillet@wanadoo.fr> wrote:
> Knowing that:
> #define TUNNEL_DST_PORT_FREE_REQ_TUNNEL_TYPE_VXLAN (0x1UL << 0)
> #define TUNNEL_DST_PORT_FREE_REQ_TUNNEL_TYPE_GENEVE (0x5UL << 0)
> and that 'bnxt_hwrm_tunnel_dst_port_alloc()' is only called with one of
> these 2 constants, the TUNNEL_DST_PORT_ALLOC_REQ_TUNNEL_TYPE_GENEVE can not
> trigger.
>
> Replace the bit test that overlap by an equality test, just as in
> 'bnxt_hwrm_tunnel_dst_port_free()' above.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Thanks.
Acked-by: Michael Chan <michael.chan@broadcom.com>
^ permalink raw reply
* [Patch net] net: revert "net: l2tp: Treat NET_XMIT_CN as success in l2tp_eth_dev_xmit"
From: Cong Wang @ 2016-11-22 7:24 UTC (permalink / raw)
To: netdev; +Cc: Cong Wang, Gao Feng
This reverts commit 7c6ae610a1f0, because l2tp_xmit_skb() never
returns NET_XMIT_CN, it ignores the return value of l2tp_xmit_core().
Cc: Gao Feng <gfree.wind@gmail.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
net/l2tp/l2tp_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/l2tp/l2tp_eth.c b/net/l2tp/l2tp_eth.c
index 3dc97b4..965f7e3 100644
--- a/net/l2tp/l2tp_eth.c
+++ b/net/l2tp/l2tp_eth.c
@@ -97,7 +97,7 @@ static int l2tp_eth_dev_xmit(struct sk_buff *skb, struct net_device *dev)
unsigned int len = skb->len;
int ret = l2tp_xmit_skb(session, skb, session->hdr_len);
- if (likely(ret == NET_XMIT_SUCCESS || ret == NET_XMIT_CN)) {
+ if (likely(ret == NET_XMIT_SUCCESS)) {
atomic_long_add(len, &priv->tx_bytes);
atomic_long_inc(&priv->tx_packets);
} else {
--
1.8.4.5
^ permalink raw reply related
* Re: [PATCH] mac80211: Remove unused 'struct rate_control_ref' variable
From: Johannes Berg @ 2016-11-22 7:30 UTC (permalink / raw)
To: Kirtika Ruchandani
Cc: Arnd Bergmann, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Maxim Altshul
In-Reply-To: <20161122065416.GA3565-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
On Mon, 2016-11-21 at 22:54 -0800, Kirtika Ruchandani wrote:
> Commit 3b17fbf87d5d introduced sta_get_expected_throughput()
> leaving variable 'struct rate_control_ref* ref' set but unused.
> Compiling with W=1 gives the following warning, fix it.
>
> net/mac80211/sta_info.c: In function ‘sta_set_sinfo’:
> net/mac80211/sta_info.c:2052:27: warning: variable ‘ref’ set but not
> used [-Wunused-but-set-variable]
Applied all three of these, thanks Kirtika.
johannes
^ permalink raw reply
* Re: [PATCH] net: ioctl SIOCSIFADDR minor cleanup
From: Cong Wang @ 2016-11-22 7:32 UTC (permalink / raw)
To: YUAN Linyu; +Cc: David Miller, cugyly@163.com, netdev@vger.kernel.org
In-Reply-To: <8729016553E3654398EA69218DA29EEF0E431D3A@cnshjmbx02>
On Mon, Nov 21, 2016 at 8:30 PM, YUAN Linyu
<Linyu.Yuan@alcatel-sbell.com.cn> wrote:
> I think there are newbie include me still use ifconfig utility.
> So when I check this code, it can be optimized.
>
Working on Linux kernel is always welcome.
But I don't think this can convince DaveM to take your patch even
if it is really correct (I never check).
^ permalink raw reply
* Re: [PATCH iproute2 2/2] tc/act_tunnel: Introduce ip tunnel action
From: Amir Vadai @ 2016-11-22 7:50 UTC (permalink / raw)
To: Rosen, Rami
Cc: Stephen Hemminger, David S. Miller, netdev@vger.kernel.org,
Or Gerlitz, Hadar Har-Zion, Roi Dayan
In-Reply-To: <9B0331B6EBBD0E4684FBFAEDA55776F93D345ED8@HASMSX110.ger.corp.intel.com>
On Mon, Nov 21, 2016 at 11:50:03PM +0000, Rosen, Rami wrote:
> Hi, Amir,
>
> Following are three minor comments:
>
> Seems that TCA_TUNNEL_KEY_PAD used anywhere:
I assume you ment that it is _NOT_ used anywhere:
This attribute type is used in the kernel side only - for padding 64bit
attributes. The userspace enum should match the kernel include/uapi one.
>
> + TCA_TUNNEL_KEY_PAD,
> + __TCA_TUNNEL_KEY_MAX,
> +};
>
>
> Should be "and destination IP 11.11.0.2" instead of "and destination IP 11.11.0.1":
ack
>
> +Tunnel ID (for example VNI in VXLAN tunnel) .TP .B src_ip Outer header
> +source IP address (IPv4 or IPv6) .TP .B dst_ip Outer header destination
> +IP address (IPv4 or IPv6) .RE .SH EXAMPLES The following example
> +encapsulates incoming ICMP packets on eth0 into a vxlan tunnel by
> +setting metadata to VNI 11, source IP 11.11.0.1 and destination IP
> +11.11.0.1 by forwarding the skb with the metadata to device vxlan0,
> +which will prepare the VXLAN headers:
> +
> +.RS
> +.EX
> +#tc qdisc add dev eth0 handle ffff: ingress #tc filter add dev eth0
> +protocol ip parent ffff: \\
> + flower \\
> + ip_proto icmp \\
> + action tunnel_key set \\
> + src_ip 11.11.0.1 \\
> + dst_ip 11.11.0.2 \\
> + id 11 \\
>
>
> Typo: should be "ip tunnel" instead of "ip tunel":
ack
>
> + * m_tunnel_key.c ip tunel manipulation module
> + *
> + * This program is free software; you can redistribute it and/or
>
> Keep on the good work!
Thanks for reviewing,
Amir
>
> Regards,
> Rami Rosen
> Intel Corporation
^ permalink raw reply
* Re: [net-next PATCH v2 1/5] net: virtio dynamically disable/enable LRO
From: John Fastabend @ 2016-11-22 8:16 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: daniel, eric.dumazet, kubakici, shm, davem, alexei.starovoitov,
netdev, bblanco, john.r.fastabend, brouer, tgraf
In-Reply-To: <20161122012202-mutt-send-email-mst@kernel.org>
On 16-11-21 03:23 PM, Michael S. Tsirkin wrote:
> On Sat, Nov 19, 2016 at 06:49:34PM -0800, John Fastabend wrote:
>> This adds support for dynamically setting the LRO feature flag. The
>> message to control guest features in the backend uses the
>> CTRL_GUEST_OFFLOADS msg type.
>>
>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>> ---
>> drivers/net/virtio_net.c | 45 ++++++++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 44 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>> index ca5239a..8189e5b 100644
>> --- a/drivers/net/virtio_net.c
>> +++ b/drivers/net/virtio_net.c
>> @@ -1419,6 +1419,41 @@ static void virtnet_init_settings(struct net_device *dev)
>> .set_settings = virtnet_set_settings,
>> };
>>
>> +static int virtnet_set_features(struct net_device *netdev,
>> + netdev_features_t features)
>> +{
>> + struct virtnet_info *vi = netdev_priv(netdev);
>> + struct virtio_device *vdev = vi->vdev;
>> + struct scatterlist sg;
>> + u64 offloads = 0;
>> +
>> + if (features & NETIF_F_LRO)
>> + offloads |= (1 << VIRTIO_NET_F_GUEST_TSO4) |
>> + (1 << VIRTIO_NET_F_GUEST_TSO6);
>> +
>> + if (features & NETIF_F_RXCSUM)
>> + offloads |= (1 << VIRTIO_NET_F_GUEST_CSUM);
>> +
>> + if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS)) {
>> + sg_init_one(&sg, &offloads, sizeof(uint64_t));
>> + if (!virtnet_send_command(vi,
>> + VIRTIO_NET_CTRL_GUEST_OFFLOADS,
>> + VIRTIO_NET_CTRL_GUEST_OFFLOADS_SET,
>> + &sg)) {
>> + dev_warn(&netdev->dev,
>> + "Failed to set guest offloads by virtnet command.\n");
>> + return -EINVAL;
>> + }
>> + } else if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS) &&
>> + !virtio_has_feature(vdev, VIRTIO_F_VERSION_1)) {
>> + dev_warn(&netdev->dev,
>> + "No support for setting offloads pre version_1.\n");
>> + return -EINVAL;
>> + }
>
> I don't get this last warning. VIRTIO_NET_F_CTRL_GUEST_OFFLOADS
> was exposes by legacy devices, I don't think it's related to
> VIRTIO_F_VERSION_1.
>
OK looks like I can just drop the else if branch here.
Thanks,
John
^ permalink raw reply
* Re: [net-next PATCH v2 4/5] virtio_net: add dedicated XDP transmit queues
From: John Fastabend @ 2016-11-22 8:17 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: daniel, eric.dumazet, kubakici, shm, davem, alexei.starovoitov,
netdev, bblanco, john.r.fastabend, brouer, tgraf
In-Reply-To: <20161121234008-mutt-send-email-mst@kernel.org>
On 16-11-21 03:13 PM, Michael S. Tsirkin wrote:
> On Sat, Nov 19, 2016 at 06:51:04PM -0800, John Fastabend wrote:
>> XDP requires using isolated transmit queues to avoid interference
>> with normal networking stack (BQL, NETDEV_TX_BUSY, etc). This patch
>> adds a XDP queue per cpu when a XDP program is loaded and does not
>> expose the queues to the OS via the normal API call to
>> netif_set_real_num_tx_queues(). This way the stack will never push
>> an skb to these queues.
>>
>> However virtio/vhost/qemu implementation only allows for creating
>> TX/RX queue pairs at this time so creating only TX queues was not
>> possible. And because the associated RX queues are being created I
>> went ahead and exposed these to the stack and let the backend use
>> them. This creates more RX queues visible to the network stack than
>> TX queues which is worth mentioning but does not cause any issues as
>> far as I can tell.
>>
>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>
> FYI what's supposed to happen is packets from the same
> flow going in the reverse direction will go on the
> same queue.
>
> This might come in handy when implementing RX XDP.
>
Yeah but if its the first packet not part of a flow then presumably it
can pick any queue but its worth keeping in mind certainly.
.John
^ permalink raw reply
* Re: linux-next: build warnings after merge of the net-next tree
From: Thomas Petazzoni @ 2016-11-22 8:23 UTC (permalink / raw)
To: Florian Fainelli
Cc: Stephen Rothwell, David Miller, Networking, linux-next,
linux-kernel, Gregory Clement
In-Reply-To: <e5c5a4d7-355e-b8a6-9526-d6acbe4e54f8@gmail.com>
Hello,
On Mon, 21 Nov 2016 17:28:39 -0800, Florian Fainelli wrote:
> +Thomas, Gregory,
>
> On 11/21/2016 05:22 PM, Stephen Rothwell wrote:
> [snip]
> >
> > Introduced by commit
> >
> > a0627f776a45 ("net: marvell: Allow drivers to be built with COMPILE_TEST")
> >
> > "a few warnings" is a matter of perception. :-(
>
> Thomas, based on our IRC conversation, do you already have patches for
> mvneta and mvpp2 to build without warning on 64-bit or should I prepare
> patches for these?
Yes, we already have patches for making mvneta and mvpp2 build without
warning for 64-bit (Grégory for mvneta, and myself for mvpp2). I
intended to send the mvpp2 ones together with patches adding support
for a new variant of the IP, but I guess I can send just the few ones
that make it 64-bit "buildable".
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ 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