* [PATCH 5/5] netfilter: nf_tables: Fix nft limit burst handling
From: Pablo Neira Ayuso @ 2017-08-24 14:43 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1503585811-13447-1-git-send-email-pablo@netfilter.org>
From: andy zhou <azhou@ovn.org>
Current implementation treats the burst configuration the same as
rate configuration. This can cause the per packet cost to be lower
than configured. In effect, this bug causes the token bucket to be
refilled at a higher rate than what user has specified.
This patch changes the implementation so that the token bucket size
is controlled by "rate + burst", while maintain the token bucket
refill rate the same as user specified.
Fixes: 96518518cc41 ("netfilter: add nftables")
Signed-off-by: Andy Zhou <azhou@ovn.org>
Acked-by: Joe Stringer <joe@ovn.org>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nft_limit.c | 25 ++++++++++++++-----------
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/net/netfilter/nft_limit.c b/net/netfilter/nft_limit.c
index 18dd57a52651..14538b1d4d11 100644
--- a/net/netfilter/nft_limit.c
+++ b/net/netfilter/nft_limit.c
@@ -65,19 +65,23 @@ static int nft_limit_init(struct nft_limit *limit,
limit->nsecs = unit * NSEC_PER_SEC;
if (limit->rate == 0 || limit->nsecs < unit)
return -EOVERFLOW;
- limit->tokens = limit->tokens_max = limit->nsecs;
-
- if (tb[NFTA_LIMIT_BURST]) {
- u64 rate;
+ if (tb[NFTA_LIMIT_BURST])
limit->burst = ntohl(nla_get_be32(tb[NFTA_LIMIT_BURST]));
+ else
+ limit->burst = 0;
+
+ if (limit->rate + limit->burst < limit->rate)
+ return -EOVERFLOW;
- rate = limit->rate + limit->burst;
- if (rate < limit->rate)
- return -EOVERFLOW;
+ /* The token bucket size limits the number of tokens can be
+ * accumulated. tokens_max specifies the bucket size.
+ * tokens_max = unit * (rate + burst) / rate.
+ */
+ limit->tokens = div_u64(limit->nsecs * (limit->rate + limit->burst),
+ limit->rate);
+ limit->tokens_max = limit->tokens;
- limit->rate = rate;
- }
if (tb[NFTA_LIMIT_FLAGS]) {
u32 flags = ntohl(nla_get_be32(tb[NFTA_LIMIT_FLAGS]));
@@ -95,9 +99,8 @@ static int nft_limit_dump(struct sk_buff *skb, const struct nft_limit *limit,
{
u32 flags = limit->invert ? NFT_LIMIT_F_INV : 0;
u64 secs = div_u64(limit->nsecs, NSEC_PER_SEC);
- u64 rate = limit->rate - limit->burst;
- if (nla_put_be64(skb, NFTA_LIMIT_RATE, cpu_to_be64(rate),
+ if (nla_put_be64(skb, NFTA_LIMIT_RATE, cpu_to_be64(limit->rate),
NFTA_LIMIT_PAD) ||
nla_put_be64(skb, NFTA_LIMIT_UNIT, cpu_to_be64(secs),
NFTA_LIMIT_PAD) ||
--
2.1.4
^ permalink raw reply related
* Re: [V3 PATCH net-next 0/5] xdp: more work on xdp tracepoints
From: John Fastabend @ 2017-08-24 14:46 UTC (permalink / raw)
To: Jesper Dangaard Brouer, netdev; +Cc: Daniel Borkmann
In-Reply-To: <150357074701.26663.4047992776649697788.stgit@firesoul>
On 08/24/2017 03:32 AM, Jesper Dangaard Brouer wrote:
> More work on streamlining and performance optimizing the tracepoints
> for XDP.
>
> I've created a simple xdp_monitor application that uses this
> tracepoint, and prints statistics. Available at github:
>
> https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/samples/bpf/xdp_monitor_kern.c
> https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/samples/bpf/xdp_monitor_user.c
>
> The improvement over tracepoint with strcpy: 9810372 - 8428762 = +1381610 pps faster
> - (1/9810372 - 1/8428762)*10^9 = -16.7 nanosec
> - 100-(8428762/9810372*100) = strcpy-trace is 14.08% slower
> - 981037/8428762*100 = removing strcpy made it 11.64% faster
>
> V3: Fix merge conflict with commit e4a8e817d3cb ("bpf: misc xdp redirect cleanups")
> V2: Change trace_xdp_redirect() to align with args of trace_xdp_exception()
>
> ---
Series looks good to me. Thanks a lot.
^ permalink raw reply
* Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of the PHY mode
From: Andrew Lunn @ 2017-08-24 14:56 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, kishon, jason, sebastian.hesselbarth, gregory.clement,
thomas.petazzoni, nadavh, linux, linux-kernel, mw, stefanc,
miquel.raynal, netdev
In-Reply-To: <20170824083823.16826-10-antoine.tenart@free-electrons.com>
On Thu, Aug 24, 2017 at 10:38:19AM +0200, Antoine Tenart wrote:
> This patch adds logic to reconfigure the comphy/gop when the link status
> change at runtime. This is very useful on boards such as the mcbin which
> have SFP and Ethernet ports connected to the same MAC port: depending on
> what the user connects the driver will automatically reconfigure the
> link mode.
Hi Antoine
I would expect each of these external Ethernet ports to have its own
Ethernet PHY. Don't you need to disconnect from one Ethernet phy and
connect to the other Ethernet PHY when you change external Ethernet
port?
Andrew
^ permalink raw reply
* Re: [PATCH net-next] net-next/hinic: Fix MTU limitation
From: Andrew Lunn @ 2017-08-24 15:19 UTC (permalink / raw)
To: Aviad Krawczyk; +Cc: davem, linux-kernel, netdev, zhaochen6
In-Reply-To: <1503580885-35180-1-git-send-email-aviad.krawczyk@huawei.com>
On Thu, Aug 24, 2017 at 09:21:25PM +0800, Aviad Krawczyk wrote:
> Fix the hw MTU limitation by setting min/max_mtu
>
> Signed-off-by: Aviad Krawczyk <aviad.krawczyk@huawei.com>
> Signed-off-by: Zhao Chen <zhaochen6@huawei.com>
> ---
> drivers/net/ethernet/huawei/hinic/hinic_main.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/ethernet/huawei/hinic/hinic_main.c b/drivers/net/ethernet/huawei/hinic/hinic_main.c
> index ae7ad48..7a14963 100644
> --- a/drivers/net/ethernet/huawei/hinic/hinic_main.c
> +++ b/drivers/net/ethernet/huawei/hinic/hinic_main.c
> @@ -980,6 +980,9 @@ static int nic_dev_init(struct pci_dev *pdev)
> hinic_hwdev_cb_register(nic_dev->hwdev, HINIC_MGMT_MSG_CMD_LINK_STATUS,
> nic_dev, link_status_event_handler);
>
> + netdev->min_mtu = ETH_MIN_MTU;
You don't need to set the min_mtu. See:
http://elixir.free-electrons.com/linux/latest/source/net/ethernet/eth.c#L354
Andrew
^ permalink raw reply
* Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of the PHY mode
From: Antoine Tenart @ 2017-08-24 15:52 UTC (permalink / raw)
To: Andrew Lunn
Cc: Antoine Tenart, davem, kishon, jason, sebastian.hesselbarth,
gregory.clement, thomas.petazzoni, nadavh, linux, linux-kernel,
mw, stefanc, miquel.raynal, netdev
In-Reply-To: <20170824145609.GJ8022@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 1084 bytes --]
Hi Andrew,
On Thu, Aug 24, 2017 at 04:56:09PM +0200, Andrew Lunn wrote:
> On Thu, Aug 24, 2017 at 10:38:19AM +0200, Antoine Tenart wrote:
> > This patch adds logic to reconfigure the comphy/gop when the link status
> > change at runtime. This is very useful on boards such as the mcbin which
> > have SFP and Ethernet ports connected to the same MAC port: depending on
> > what the user connects the driver will automatically reconfigure the
> > link mode.
>
> I would expect each of these external Ethernet ports to have its own
> Ethernet PHY. Don't you need to disconnect from one Ethernet phy and
> connect to the other Ethernet PHY when you change external Ethernet
> port?
That's the other way around. The engines outputs (say GoP#) are
connected to the comphy inputs. In the SoC. Then there's a single output
of this comphy lane to the board. So when switching modes, you do not
have to connect to a different Ethernet PHY, it's the same.
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 3/3] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK)
From: Stefan Hajnoczi @ 2017-08-24 15:53 UTC (permalink / raw)
To: Dexuan Cui
Cc: Michal Kubecek, joe@perches.com, olaf@aepfle.de,
Stephen Hemminger, jasowang@redhat.com, netdev@vger.kernel.org,
Haiyang Zhang, Dave Scott, linux-kernel@vger.kernel.org,
apw@canonical.com, Jorgen Hansen, Rolf Neugebauer, Marcelo Cerri,
devel@linuxdriverproject.org, Vitaly Kuznetsov,
davem@davemloft.net, George Zhang, Dan Carpenter
In-Reply-To: <PS1P15301MB0011D3F00204245172E8150EBF840@PS1P15301MB0011.APCP153.PROD.OUTLOOK.COM>
On Tue, Aug 22, 2017 at 09:40:01PM +0000, Dexuan Cui wrote:
> > From: Stefan Hajnoczi [mailto:stefanha@redhat.com]
> > On Fri, Aug 18, 2017 at 10:23:54PM +0000, Dexuan Cui wrote:
> > > > > +static bool hvs_stream_allow(u32 cid, u32 port)
> > > > > +{
> > > > > + static const u32 valid_cids[] = {
> > > > > + VMADDR_CID_ANY,
> > > >
> > > > Is this for loopback?
> > >
> > > No, we don't support lookback in Linux VM, at least for now.
> > > In our Linux implementation, Linux VM can only connect to the host, and
> > > here when Linux VM calls connect(), I treat VMADDR_CID_ANY
> > > the same as VMADDR_CID_HOST.
> >
> > VMCI and virtio-vsock do not treat connect(VMADDR_CID_ANY) the same as
> > connect(VMADDR_CID_HOST). It is an error to connect to VMADDR_CID_ANY.
>
> Ok. Then I'll only allow VMADDR_CID_HOST as the destination CID, since
> we don't support loopback mode.
>
> > > > > + /* The host's port range [MIN_HOST_EPHEMERAL_PORT, 0xFFFFFFFF)
> > > > is
> > > > > + * reserved as ephemeral ports, which are used as the host's ports
> > > > > + * when the host initiates connections.
> > > > > + */
> > > > > + if (port > MAX_HOST_LISTEN_PORT)
> > > > > + return false;
> > > >
> > > > Without this if statement the guest will attempt to connect. I guess
> > > > there will be no listen sockets above MAX_HOST_LISTEN_PORT, so the
> > > > connection attempt will fail.
> > >
> > > You're correct.
> > > To use the vsock common infrastructure, we have to map Hyper-V's
> > > GUID <VM_ID, Service_ID> to int <cid, port>, and hence we must limit
> > > the port range we can listen() on to [0, MAX_LISTEN_PORT], i.e.
> > > we can only use half of the whole 32-bit port space for listen().
> > > This is detailed in the long comments starting at about Line 100.
> > >
> > > > ...but hardcode this knowledge into the guest driver?
> > > I'd like the guest's connect() to fail immediately here.
> > > IMO this is better than a connect timeout. :-)
> >
> > Thanks for explaining. Perhaps the comment could be updated:
> >
> > /* The host's port range [MIN_HOST_EPHEMERAL_PORT, 0xFFFFFFFF) is
> > * reserved as ephemeral ports, which are used as the host's ports when
> > * the host initiates connections.
> > *
> > * Perform this check in the guest so an immediate error is produced
> > * instead of a timeout.
> > */
> >
> > Stefan
>
> Thank you, Stefan!
> Please see the below for the updated version of the function:
>
> static bool hvs_stream_allow(u32 cid, u32 port)
> {
> /* The host's port range [MIN_HOST_EPHEMERAL_PORT, 0xFFFFFFFF) is
> * reserved as ephemeral ports, which are used as the host's ports
> * when the host initiates connections.
> *
> * Perform this check in the guest so an immediate error is produced
> * instead of a timeout.
> */
> if (port > MAX_HOST_LISTEN_PORT)
> return false;
>
> if (cid == VMADDR_CID_HOST)
> return true;
>
> return false;
> }
>
> I'll send a v2 of the patch later today.
Great, thanks!
^ permalink raw reply
* Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of the PHY mode
From: Andrew Lunn @ 2017-08-24 16:01 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, kishon, jason, sebastian.hesselbarth, gregory.clement,
thomas.petazzoni, nadavh, linux, linux-kernel, mw, stefanc,
miquel.raynal, netdev
In-Reply-To: <20170824155241.GF28443@kwain>
On Thu, Aug 24, 2017 at 05:52:41PM +0200, Antoine Tenart wrote:
> Hi Andrew,
>
> On Thu, Aug 24, 2017 at 04:56:09PM +0200, Andrew Lunn wrote:
> > On Thu, Aug 24, 2017 at 10:38:19AM +0200, Antoine Tenart wrote:
> > > This patch adds logic to reconfigure the comphy/gop when the link status
> > > change at runtime. This is very useful on boards such as the mcbin which
> > > have SFP and Ethernet ports connected to the same MAC port: depending on
> > > what the user connects the driver will automatically reconfigure the
> > > link mode.
> >
> > I would expect each of these external Ethernet ports to have its own
> > Ethernet PHY. Don't you need to disconnect from one Ethernet phy and
> > connect to the other Ethernet PHY when you change external Ethernet
> > port?
>
> That's the other way around. The engines outputs (say GoP#) are
> connected to the comphy inputs. In the SoC. Then there's a single output
> of this comphy lane to the board. So when switching modes, you do not
> have to connect to a different Ethernet PHY, it's the same.
Hi Antoine
I think there is a mixup here between generic PHY and Ethernet PHY.
When you swap from the copper RJ45 to the fibre SFP, the phylib needs
to swap from the Copper Ethernet PHY driving the RJ45, to the PHY
driving the SFP module, which is probably a fixed-phy.
I actually think this is why you have the carrier_on/off calls in the
link modify callback.
Imagine phylib is using the copper Ethernet PHY, but the MAC is using
the SFP port. Somebody pulls out the copper cable, phylib says the
link is down, turns the carrier off and calls the callback. Not good,
since your SFP cable is still plugged in... Ethtool is
returning/setting stuff in the Copper Ethernet PHY, when in fact you
intend to be setting SFP settings.
Andrew
^ permalink raw reply
* [PATCH net] virtio_net: be drop monitor friend
From: Eric Dumazet @ 2017-08-24 16:02 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Michael S. Tsirkin, Jason Wang
From: Eric Dumazet <edumazet@google.com>
This change is needed to not fool drop monitor.
(perf record ... -e skb:kfree_skb )
Packets were properly sent and are consumed after TX completion.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
drivers/net/virtio_net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 98f17b05c68b..b06169ea60dc 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1058,7 +1058,7 @@ static void free_old_xmit_skbs(struct send_queue *sq)
bytes += skb->len;
packets++;
- dev_kfree_skb_any(skb);
+ dev_consume_skb_any(skb);
}
/* Avoid overhead when no packets have been processed
^ permalink raw reply related
* Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of the PHY mode
From: Antoine Tenart @ 2017-08-24 16:19 UTC (permalink / raw)
To: Andrew Lunn
Cc: Antoine Tenart, davem, kishon, jason, sebastian.hesselbarth,
gregory.clement, thomas.petazzoni, nadavh, linux, linux-kernel,
mw, stefanc, miquel.raynal, netdev
In-Reply-To: <20170824160124.GA18700@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 2621 bytes --]
On Thu, Aug 24, 2017 at 06:01:24PM +0200, Andrew Lunn wrote:
> On Thu, Aug 24, 2017 at 05:52:41PM +0200, Antoine Tenart wrote:
> > On Thu, Aug 24, 2017 at 04:56:09PM +0200, Andrew Lunn wrote:
> > > On Thu, Aug 24, 2017 at 10:38:19AM +0200, Antoine Tenart wrote:
> > > > This patch adds logic to reconfigure the comphy/gop when the link status
> > > > change at runtime. This is very useful on boards such as the mcbin which
> > > > have SFP and Ethernet ports connected to the same MAC port: depending on
> > > > what the user connects the driver will automatically reconfigure the
> > > > link mode.
> > >
> > > I would expect each of these external Ethernet ports to have its own
> > > Ethernet PHY. Don't you need to disconnect from one Ethernet phy and
> > > connect to the other Ethernet PHY when you change external Ethernet
> > > port?
> >
> > That's the other way around. The engines outputs (say GoP#) are
> > connected to the comphy inputs. In the SoC. Then there's a single output
> > of this comphy lane to the board. So when switching modes, you do not
> > have to connect to a different Ethernet PHY, it's the same.
>
> I think there is a mixup here between generic PHY and Ethernet PHY.
>
> When you swap from the copper RJ45 to the fibre SFP, the phylib needs
> to swap from the Copper Ethernet PHY driving the RJ45, to the PHY
> driving the SFP module, which is probably a fixed-phy.
Or on the mcbin the Alaska X 88X3310 which can operate from 10G to 10M.
This PHY changes its interface mode depending on what speed is
negotiated.
> I actually think this is why you have the carrier_on/off calls in the
> link modify callback.
Well, I still do not know if these calls are *really* needed. At least
in our case.
> Imagine phylib is using the copper Ethernet PHY, but the MAC is using
> the SFP port. Somebody pulls out the copper cable, phylib says the
> link is down, turns the carrier off and calls the callback. Not good,
> since your SFP cable is still plugged in... Ethtool is
> returning/setting stuff in the Copper Ethernet PHY, when in fact you
> intend to be setting SFP settings.
I see what could be the issue but I do not understand one aspect though:
how could we switch from one PHY to another, as there's only one output
between the SoC (and so a given GoP#) and the board. So if a given PHY
can handle multiple modes I see, but in the other case a muxing
somewhere would be needed? Or did I miss something?
Thanks!
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2] netfilter: nf_nat_h323: fix logical-not-parentheses warning
From: Nick Desaulniers @ 2017-08-24 16:25 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Matthias Kaehlcke, Lorenzo Colitti, Nick Desaulniers,
Jozsef Kadlecsik, Florian Westphal, David S. Miller,
Alexey Kuznetsov, Hideaki YOSHIFUJI, netfilter-devel, coreteam,
netdev, linux-kernel
In-Reply-To: <CAKwvOdmw+bnN-nKeKbE8WJJ8Enc4PCeC3KD5KpaSVOT4+ycDKQ@mail.gmail.com>
bumping for review (resending, had gmail set to html mode)
On Mon, Aug 14, 2017 at 10:36 AM, Nick Desaulniers
<ndesaulniers@google.com> wrote:
> Minor nit for the commit message that can get fixed up when being merged:
>
> On Fri, Aug 11, 2017 at 11:16 AM, Nick Desaulniers
> <ndesaulniers@google.com> wrote:
>
>> if (x)
>> return
>> ...
>>
>> rather than:
>>
>> if (!x == 0)
>
> should remove the `!`, ex:
>
> if (x == 0)
>
>> ...
>> else
>> return
>
> --
> Thanks,
> ~Nick Desaulniers
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* Re: [patch net-next 00/12] mlxsw: Add IPv4 host dpipe table
From: David Miller @ 2017-08-24 16:33 UTC (permalink / raw)
To: jiri; +Cc: netdev, arkadis, idosch, mlxsw
In-Reply-To: <20170824064010.1646-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Thu, 24 Aug 2017 08:39:58 +0200
> From: Jiri Pirko <jiri@mellanox.com>
>
> Arkadi says:
>
> This patchset adds IPv4 host dpipe table support. This will provide the
> ability to observe the hardware offloaded IPv4 neighbors.
Looks really nice, series applied, thanks.
^ permalink raw reply
* Re: [PATCH v3] net: stmmac: Delete dead code for MDIO registration
From: David Miller @ 2017-08-24 16:34 UTC (permalink / raw)
To: romain.perier
Cc: f.fainelli, peppe.cavallaro, alexandre.torgue, andrew, netdev,
linux-kernel
In-Reply-To: <10e0ebf9-b412-8547-d0d7-01a958edbcd9@collabora.com>
From: Romain Perier <romain.perier@collabora.com>
Date: Thu, 24 Aug 2017 08:49:18 +0200
> Le 23/08/2017 à 18:46, Florian Fainelli a écrit :
>> On 08/23/2017 01:50 AM, Romain Perier wrote:
>>> This code is no longer used, the logging function was changed by commit
>>> fbca164776e4 ("net: stmmac: Use the right logging functi"). It was
>>> previously showing information about the type if the IRQ, if it's polled,
>>> ignored or a normal interrupt. As we don't want information loss, I have
>>> moved this code to phy_attached_print().
>>>
>>> Fixes: fbca164776e4 ("net: stmmac: Use the right logging functi")
>> For future submissions, do not truncate the commit subject that you are
>> referencing.
>
> Even if it exceeds 72 characters ?
Yes, always.
^ permalink raw reply
* Re: [PATCH net-next v4] net: stmmac: Delete dead code for MDIO registration
From: David Miller @ 2017-08-24 16:36 UTC (permalink / raw)
To: romain.perier
Cc: peppe.cavallaro, alexandre.torgue, andrew, f.fainelli, netdev,
linux-kernel
In-Reply-To: <20170824070317.10265-1-romain.perier@collabora.com>
From: Romain Perier <romain.perier@collabora.com>
Date: Thu, 24 Aug 2017 09:03:17 +0200
> This code is no longer used, the logging function was changed by commit
> fbca164776e4 ("net: stmmac: Use the right logging functi").
You're truncating the commit header text here too, please fix this.
^ permalink raw reply
* Re: [PATCH net-next] net-next/hinic: Fix MTU limitation
From: Aviad Krawczyk @ 2017-08-24 16:41 UTC (permalink / raw)
To: Andrew Lunn; +Cc: davem, linux-kernel, netdev, zhaochen6
In-Reply-To: <20170824151958.GL8022@lunn.ch>
On 8/24/2017 6:19 PM, Andrew Lunn wrote:
> On Thu, Aug 24, 2017 at 09:21:25PM +0800, Aviad Krawczyk wrote:
>> Fix the hw MTU limitation by setting min/max_mtu
>>
>> Signed-off-by: Aviad Krawczyk <aviad.krawczyk@huawei.com>
>> Signed-off-by: Zhao Chen <zhaochen6@huawei.com>
>> ---
>> drivers/net/ethernet/huawei/hinic/hinic_main.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/huawei/hinic/hinic_main.c b/drivers/net/ethernet/huawei/hinic/hinic_main.c
>> index ae7ad48..7a14963 100644
>> --- a/drivers/net/ethernet/huawei/hinic/hinic_main.c
>> +++ b/drivers/net/ethernet/huawei/hinic/hinic_main.c
>> @@ -980,6 +980,9 @@ static int nic_dev_init(struct pci_dev *pdev)
>> hinic_hwdev_cb_register(nic_dev->hwdev, HINIC_MGMT_MSG_CMD_LINK_STATUS,
>> nic_dev, link_status_event_handler);
>>
>> + netdev->min_mtu = ETH_MIN_MTU;
>
> You don't need to set the min_mtu. See:
>
> http://elixir.free-electrons.com/linux/latest/source/net/ethernet/eth.c#L354
>
> Andrew
>
> .
>
Thanks for paying attention to this unuseful line, I don't need to set min mtu.
I added it by mistake, the target was to change the MTU limitation.
I will send the patch soon without this line(in few days, after we will test it)
^ permalink raw reply
* Re: [PATCH v3 0/7] Add RSS to DPAA 1.x Ethernet driver
From: David Miller @ 2017-08-24 16:42 UTC (permalink / raw)
To: madalin.bucur; +Cc: netdev, linuxppc-dev, linux-kernel
In-Reply-To: <1503559708-13405-1-git-send-email-madalin.bucur@nxp.com>
From: Madalin Bucur <madalin.bucur@nxp.com>
Date: Thu, 24 Aug 2017 10:28:21 +0300
> This patch set introduces Receive Side Scaling for the DPAA Ethernet
> driver. Documentation is updated with details related to the new
> feature and limitations that apply.
> Added also a small fix.
>
> v2: removed a C++ style comment
> v3: move struct fman to header file to avoid exporting a function
Series applied, thanks.
^ permalink raw reply
* Dear Talented
From: Kim Sharma @ 2017-08-24 16:14 UTC (permalink / raw)
To: Recipients
Dear Talented,
I am Talent Scout For BLUE SKY FILM STUDIO, Present Blue sky Studio a
Film Corporation Located in the United State, is Soliciting for the
Right to use Your Photo/Face and Personality as One of the Semi -Major
Role/ Character in our Upcoming ANIMATED Stereoscope 3D Movie-The Story
of Anubis (Anubis 2018) The Movie is Currently Filming (In
Production) Please Note That There Will Be No Auditions, Traveling or
Any Special / Professional Acting Skills, Since the Production of This
Movie Will Be Done with our State of Art Computer -Generating Imagery
Equipment. We Are Prepared to Pay the Total Sum of $620,000.00 USD. For
More Information/Understanding, Please Write us on the E-Mail Below.
CONTACT EMAIL: bluesky.filmstudio@usa.com
All Reply to: bluesky.filmstudio@usa.com
Note: Only the Response send to this mail will be Given a Prior
Consideration.
Talent Scout
Kim Sharma
^ permalink raw reply
* Re: [PATCH v2] netfilter: nf_nat_h323: fix logical-not-parentheses warning
From: Pablo Neira Ayuso @ 2017-08-24 16:49 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Matthias Kaehlcke, Lorenzo Colitti, Jozsef Kadlecsik,
Florian Westphal, David S. Miller, Alexey Kuznetsov,
Hideaki YOSHIFUJI, netfilter-devel, coreteam, netdev,
linux-kernel
In-Reply-To: <CAKwvOdmw+bnN-nKeKbE8WJJ8Enc4PCeC3KD5KpaSVOT4+ycDKQ@mail.gmail.com>
On Mon, Aug 14, 2017 at 10:36:03AM -0700, Nick Desaulniers wrote:
> Minor nit for the commit message that can get fixed up when being merged:
>
> On Fri, Aug 11, 2017 at 11:16 AM, Nick Desaulniers
> <ndesaulniers@google.com> wrote:
>
> > if (x)
> > return
> > ...
> >
> > rather than:
> >
> > if (!x == 0)
>
> should remove the `!`, ex:
>
> if (x == 0)
Amended this here, and applied. Thanks!
^ permalink raw reply
* Re: [PATCH][V2] netfilter: fix indent on if statements
From: Pablo Neira Ayuso @ 2017-08-24 16:56 UTC (permalink / raw)
To: Colin King
Cc: Jozsef Kadlecsik, Florian Westphal, Stephen Hemminger,
David S . Miller, netfilter-devel, coreteam, bridge, netdev,
kernel-janitors, linux-kernel
In-Reply-To: <20170815095034.21058-1-colin.king@canonical.com>
On Tue, Aug 15, 2017 at 10:50:34AM +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> The returns on some if statements are not indented correctly,
> add in the missing tab.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of the PHY mode
From: Andrew Lunn @ 2017-08-24 16:57 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, kishon, jason, sebastian.hesselbarth, gregory.clement,
thomas.petazzoni, nadavh, linux, linux-kernel, mw, stefanc,
miquel.raynal, netdev
In-Reply-To: <20170824161945.GG28443@kwain>
> I see what could be the issue but I do not understand one aspect though:
> how could we switch from one PHY to another, as there's only one output
> between the SoC (and so a given GoP#) and the board. So if a given PHY
> can handle multiple modes I see, but in the other case a muxing
> somewhere would be needed? Or did I miss something?
I think we need a hardware diagram...
How are the RJ45, copper PHY, SFP module connected to the SoC?
Somewhere there must be a mux, to select between copper and
fibre. Where is that mux?
Andrew
^ permalink raw reply
* Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of the PHY mode
From: Russell King - ARM Linux @ 2017-08-24 16:59 UTC (permalink / raw)
To: Andrew Lunn
Cc: Antoine Tenart, davem, kishon, jason, sebastian.hesselbarth,
gregory.clement, thomas.petazzoni, nadavh, linux-kernel, mw,
stefanc, miquel.raynal, netdev
In-Reply-To: <20170824145609.GJ8022@lunn.ch>
On Thu, Aug 24, 2017 at 04:56:09PM +0200, Andrew Lunn wrote:
> On Thu, Aug 24, 2017 at 10:38:19AM +0200, Antoine Tenart wrote:
> > This patch adds logic to reconfigure the comphy/gop when the link status
> > change at runtime. This is very useful on boards such as the mcbin which
> > have SFP and Ethernet ports connected to the same MAC port: depending on
> > what the user connects the driver will automatically reconfigure the
> > link mode.
>
> Hi Antoine
>
> I would expect each of these external Ethernet ports to have its own
> Ethernet PHY. Don't you need to disconnect from one Ethernet phy and
> connect to the other Ethernet PHY when you change external Ethernet
> port?
I think you're all getting confused. The link mode has very little to
do with whether you're using SFP+ or whether you're using the RJ45 at
10G speeds. The link mode has everything to do with the speed at which
the link is negotiated at.
So please, put SFP+ out of your minds for this - SFP+ isn't the reason
why you need to switch the MAC link mode.
In all cases, the mvpp2 to 88x3310 link ends up in one of two modes:
1. SGMII for RJ45 speeds less than 10G. Autonegotiation on SGMII
at the mvpp2 end *must* be enabled for the PHY to work.
2. 10Gbase-R for 10G speeds, whether that be for SFP+ or RJ45 at 10G.
Note: mcbin does not support SFP (1G) modules on the SFP+ ports.
The 88x3310 driver in the kernel knows about these combinations and
sets the phy interface parameter correctly depending on whether the
PHY has configured itself for copper at whatever speed or SFP+.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of the PHY mode
From: Russell King - ARM Linux @ 2017-08-24 17:04 UTC (permalink / raw)
To: Andrew Lunn
Cc: Antoine Tenart, davem, kishon, jason, sebastian.hesselbarth,
gregory.clement, thomas.petazzoni, nadavh, linux-kernel, mw,
stefanc, miquel.raynal, netdev
In-Reply-To: <20170824165743.GB18700@lunn.ch>
On Thu, Aug 24, 2017 at 06:57:43PM +0200, Andrew Lunn wrote:
> > I see what could be the issue but I do not understand one aspect though:
> > how could we switch from one PHY to another, as there's only one output
> > between the SoC (and so a given GoP#) and the board. So if a given PHY
> > can handle multiple modes I see, but in the other case a muxing
> > somewhere would be needed? Or did I miss something?
>
> I think we need a hardware diagram...
>
> How are the RJ45, copper PHY, SFP module connected to the SoC?
>
> Somewhere there must be a mux, to select between copper and
> fibre. Where is that mux?
In the 88x3310 PHY:
.------- RJ45
MVPP2 ----- 88x3310 PHY
`------- SFP+
Here's the commentry I've provided at the very top of the 88x3310 driver
which describes all these modes:
* There appears to be several different data paths through the PHY which
* are automatically managed by the PHY. The following has been determined
* via observation and experimentation:
*
* SGMII PHYXS -- BASE-T PCS -- 10G PMA -- AN -- Copper (for <= 1G)
* 10GBASE-KR PHYXS -- BASE-T PCS -- 10G PMA -- AN -- Copper (for 10G)
* 10GBASE-KR PHYXS -- BASE-R PCS -- Fiber
*
* If both the fiber and copper ports are connected, the first to gain
* link takes priority and the other port is completely locked out.
It's not a copper-only PHY, it's just like most other PHYs out there
that support multiple connections, like the 88e151x series that support
both RJ45 and fibre and can auto-switch between them.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* RE: [EXT] Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of the PHY mode
From: Stefan Chulski @ 2017-08-24 17:08 UTC (permalink / raw)
To: Antoine Tenart, Andrew Lunn
Cc: davem@davemloft.net, kishon@ti.com, jason@lakedaemon.net,
sebastian.hesselbarth@gmail.com,
gregory.clement@free-electrons.com,
thomas.petazzoni@free-electrons.com, Nadav Haklai,
linux@armlinux.org.uk, linux-kernel@vger.kernel.org,
mw@semihalf.com, miquel.raynal@free-electrons.com,
netdev@vger.kernel.org
In-Reply-To: <20170824161945.GG28443@kwain>
> > Imagine phylib is using the copper Ethernet PHY, but the MAC is using
> > the SFP port. Somebody pulls out the copper cable, phylib says the
> > link is down, turns the carrier off and calls the callback. Not good,
> > since your SFP cable is still plugged in... Ethtool is
> > returning/setting stuff in the Copper Ethernet PHY, when in fact you
> > intend to be setting SFP settings.
>
> I see what could be the issue but I do not understand one aspect though:
> how could we switch from one PHY to another, as there's only one output
> between the SoC (and so a given GoP#) and the board. So if a given PHY can
> handle multiple modes I see, but in the other case a muxing somewhere would
> be needed? Or did I miss something?
I think PHY name and PHY mode struct that describe here both MAC to PHY and PHY to PHY connection create confusion...
Serdes IP lane doesn't care if connector is SFP, RJ45 or direct attached cable. mvpp22_comphy_init only configures MAC to PHY
connection. SFI for 10G(KR in mainline), SGMII for 1G and HS_SGMII for 2.5G.
Regards,
Stefan.
^ permalink raw reply
* Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of the PHY mode
From: Antoine Tenart @ 2017-08-24 17:13 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Andrew Lunn, Antoine Tenart, davem, kishon, jason,
sebastian.hesselbarth, gregory.clement, thomas.petazzoni, nadavh,
linux-kernel, mw, stefanc, miquel.raynal, netdev
In-Reply-To: <20170824170401.GA20805@n2100.armlinux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]
On Thu, Aug 24, 2017 at 06:04:01PM +0100, Russell King - ARM Linux wrote:
> On Thu, Aug 24, 2017 at 06:57:43PM +0200, Andrew Lunn wrote:
> > > I see what could be the issue but I do not understand one aspect though:
> > > how could we switch from one PHY to another, as there's only one output
> > > between the SoC (and so a given GoP#) and the board. So if a given PHY
> > > can handle multiple modes I see, but in the other case a muxing
> > > somewhere would be needed? Or did I miss something?
> >
> > I think we need a hardware diagram...
> >
> > How are the RJ45, copper PHY, SFP module connected to the SoC?
> >
> > Somewhere there must be a mux, to select between copper and
> > fibre. Where is that mux?
>
> In the 88x3310 PHY:
>
> .------- RJ45
> MVPP2 ----- 88x3310 PHY
> `------- SFP+
And the "MVPP2" part can be expended to:
.-- GoP #0 --.
MVPP2 ----- GoP #1 ---- Comphy lane #X -- 88x3310
`-- GoP #2 --'
Thanks!
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [EXT] Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of the PHY mode
From: Antoine Tenart @ 2017-08-24 17:14 UTC (permalink / raw)
To: Stefan Chulski
Cc: Antoine Tenart, Andrew Lunn, davem@davemloft.net, kishon@ti.com,
jason@lakedaemon.net, sebastian.hesselbarth@gmail.com,
gregory.clement@free-electrons.com,
thomas.petazzoni@free-electrons.com, Nadav Haklai,
linux@armlinux.org.uk, linux-kernel@vger.kernel.org,
mw@semihalf.com, miquel.raynal@free-electrons.com,
netdev@vger.kernel.org
In-Reply-To: <de67e234a7ff43b49346be5cea2466eb@IL-EXCH01.marvell.com>
[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]
On Thu, Aug 24, 2017 at 05:08:29PM +0000, Stefan Chulski wrote:
> > > Imagine phylib is using the copper Ethernet PHY, but the MAC is using
> > > the SFP port. Somebody pulls out the copper cable, phylib says the
> > > link is down, turns the carrier off and calls the callback. Not good,
> > > since your SFP cable is still plugged in... Ethtool is
> > > returning/setting stuff in the Copper Ethernet PHY, when in fact you
> > > intend to be setting SFP settings.
> >
> > I see what could be the issue but I do not understand one aspect though:
> > how could we switch from one PHY to another, as there's only one output
> > between the SoC (and so a given GoP#) and the board. So if a given PHY can
> > handle multiple modes I see, but in the other case a muxing somewhere would
> > be needed? Or did I miss something?
>
> I think PHY name and PHY mode struct that describe here both MAC to
> PHY and PHY to PHY connection create confusion... Serdes IP lane
> doesn't care if connector is SFP, RJ45 or direct attached cable.
> mvpp22_comphy_init only configures MAC to PHY
> connection. SFI for 10G(KR in mainline), SGMII for 1G and HS_SGMII for
> 2.5G.
So maybe one confusion was to name them PHY_MODE_10GKR and
PHY_MODE_SGMII. It could be PHY_MODE_10G and PHY_MODE_1G instead.
Does that sound right?
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* RE: [EXT] Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of the PHY mode
From: Stefan Chulski @ 2017-08-24 17:16 UTC (permalink / raw)
To: Antoine Tenart
Cc: Andrew Lunn, davem@davemloft.net, kishon@ti.com,
jason@lakedaemon.net, sebastian.hesselbarth@gmail.com,
gregory.clement@free-electrons.com,
thomas.petazzoni@free-electrons.com, Nadav Haklai,
linux@armlinux.org.uk, linux-kernel@vger.kernel.org,
mw@semihalf.com, miquel.raynal@free-electrons.com,
netdev@vger.kernel.org
In-Reply-To: <20170824171418.GI28443@kwain>
> So maybe one confusion was to name them PHY_MODE_10GKR and
> PHY_MODE_SGMII. It could be PHY_MODE_10G and PHY_MODE_1G instead.
1G can be RGMII...
Regards,
Stefan.
^ 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