* Re: [PATCH net-next] net/sched: cls_flower: Add user specified data
From: John Fastabend @ 2017-01-02 18:23 UTC (permalink / raw)
To: Jamal Hadi Salim, Paul Blakey, David S. Miller, netdev
Cc: Jiri Pirko, Hadar Hen Zion, Or Gerlitz, Roi Dayan, Roman Mashak
In-Reply-To: <14675f63-4212-2f72-da4c-cd24b9d10881@mojatatu.com>
On 17-01-02 06:59 AM, Jamal Hadi Salim wrote:
>
> We have been using a cookie as well for actions (which we have been
> using but have been too lazy to submit so far). I am going to port
> it over to the newer kernels and post it.
> In our case that is intended to be opaque to the kernel i.e kernel
> never inteprets it; in that case it is similar to the kernel
> FIB protocol field.
>
> In your case - could this cookie have been a class/flowid
> (a 32 bit)?
> And would it not make more sense for it the cookie to be
> generic to all classifiers? i.e why is it specific to flower?
>
> cheers,
> jamal
>
> On 17-01-02 08:13 AM, Paul Blakey wrote:
>> This is to support saving extra data that might be helpful on retrieval.
>> First use case is upcoming openvswitch flow offloads, extra data will
>> include UFID and port mappings for each added flow.
>>
>> Signed-off-by: Paul Blakey <paulb@mellanox.com>
>> Reviewed-by: Roi Dayan <roid@mellanox.com>
>> Acked-by: Jiri Pirko <jiri@mellanox.com>
>> ---
Additionally I would like to point out this is an arbitrary length binary
blob (for undefined use, without even a specified encoding) that gets pushed
between user space and hardware ;) This seemed to get folks fairly excited in
the past.
Some questions, exactly what do you mean by "port mappings" above? In
general the 'tc' API uses the netdev the netlink msg is processed on as
the port mapping. If you mean OVS port to netdev port I think this is
a OVS problem and nothing to do with 'tc'. For what its worth there is an
existing problem with 'tc' where rules only apply to a single ingress or
egress port which is limiting on hardware.
The UFID in my ovs code base is defined as best I can tell here,
[OVS_FLOW_ATTR_UFID] = { .type = NL_A_UNSPEC, .optional = true,
.min_len = sizeof(ovs_u128) },
So you need 128 bits if you want a 1:1 mapping onto 'tc'. So rather
than an arbitrary blob why not make the case that 'tc' ids need to be
128 bits long? Even if its just initially done in flower call it
flower_flow_id and define it so its not opaque and at least at the code
level it isn't an arbitrary blob of data.
And what are the "next" uses of this besides OVS. It would be really
valuable to see how this generalizes to other usage models. To avoid
embedding OVS syntax into 'tc'.
Finally if you want to see an example of binary data encodings look at
how drivers/hardware/users are currently using the user defined bits in
ethtools ntuple API. Also track down out of tree drivers to see other
interesting uses. And that was capped at 64bits :/
Thanks,
John
^ permalink raw reply
* Re: tcp_bbr: Forcing set of BBR congestion control as default
From: Neal Cardwell @ 2017-01-02 18:17 UTC (permalink / raw)
To: sedat.dilek; +Cc: Netdev
In-Reply-To: <CA+icZUXd8fN5BAZuCna=zpgSJcXivSG1S6cV1eMMJMWwL7RrLA@mail.gmail.com>
On Mon, Jan 2, 2017 at 12:05 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
>
> Hi,
>
> I am trying to force the set of BBR congestion control as default.
> My old linux-config uses CUBIC as default.
> I want both BBR and CUBIC to be built but BBR shall be my default.
>
> I tried the below snippet.
>
> I refresh my new linux-config like this...
>
> $ MAKE="make V=1" ; COMPILER="mycompiler" ; MAKE_OPTS="CC=$COMPILER
> HOSTCC=$COMPILER" ; yes "" | $MAKE $MAKE_OPTS oldconfig && $MAKE
> $MAKE_OPTS silentoldconfig < /dev/null
>
> What am I doing wrong?
Perhaps your build directory already has an old .config file that sets
the DEFAULT_TCP_CONG to be "cubic", and your "make oldconfig" and
"make silentoldconfig" are maintaining those lines from the old
.config?
If you want to start with your existing .config but then make BBR the
default, then it might be simplest just to edit your .config directly:
-CONFIG_DEFAULT_TCP_CONG="cubic"
+CONFIG_DEFAULT_TCP_CONG="bbr"
BTW, I presume you have seen the warning in the BBR commit message or
tcp_bbr.c about ensuring that BBR is used with the "fq" qdisc:
NOTE: BBR *must* be used with the fq qdisc ("man tc-fq") with pacing
enabled, since pacing is integral to the BBR design and
implementation. BBR without pacing would not function properly, and
may incur unnecessary high packet loss rates.
The BBR quick-start guide has some details about how to build and
enable BBR and fq:
https://github.com/google/bbr/blob/master/Documentation/bbr-quick-start.md
Hope that helps,
neal
^ permalink raw reply
* Re: [PATCH - resubmit] igmp: Make igmp group member RFC 3376 compliant
From: David Miller @ 2017-01-02 18:01 UTC (permalink / raw)
To: mtesar; +Cc: haliu, kuznet, jmorris, kaber, netdev
In-Reply-To: <20170102133836.GA31184@sparky-lenivo.brq.redhat.com>
From: Michal Tesar <mtesar@redhat.com>
Date: Mon, 2 Jan 2017 14:38:36 +0100
> 5.2. Action on Reception of a Query
>
> When a system receives a Query, it does not respond immediately.
> Instead, it delays its response by a random amount of time, bounded
> by the Max Resp Time value derived from the Max Resp Code in the
> received Query message. A system may receive a variety of Queries on
> different interfaces and of different kinds (e.g., General Queries,
> Group-Specific Queries, and Group-and-Source-Specific Queries), each
> of which may require its own delayed response.
>
> Before scheduling a response to a Query, the system must first
> consider previously scheduled pending responses and in many cases
> schedule a combined response. Therefore, the system must be able to
> maintain the following state:
>
> o A timer per interface for scheduling responses to General Queries.
>
> o A per-group and interface timer for scheduling responses to Group-
> Specific and Group-and-Source-Specific Queries.
>
> o A per-group and interface list of sources to be reported in the
> response to a Group-and-Source-Specific Query.
>
> When a new Query with the Router-Alert option arrives on an
> interface, provided the system has state to report, a delay for a
> response is randomly selected in the range (0, [Max Resp Time]) where
> Max Resp Time is derived from Max Resp Code in the received Query
> message. The following rules are then used to determine if a Report
> needs to be scheduled and the type of Report to schedule. The rules
> are considered in order and only the first matching rule is applied.
>
> 1. If there is a pending response to a previous General Query
> scheduled sooner than the selected delay, no additional response
> needs to be scheduled.
>
> 2. If the received Query is a General Query, the interface timer is
> used to schedule a response to the General Query after the
> selected delay. Any previously pending response to a General
> Query is canceled.
> --8<--
>
> Currently the timer is rearmed with new random expiration time for
> every incoming query regardless of possibly already pending report.
> Which is not aligned with the above RFE.
> It also might happen that higher rate of incoming queries can
> postpone the report after the expiration time of the first query
> causing group membership loss.
>
> Now the per interface general query timer is rearmed only
> when there is no pending report already scheduled on that interface or
> the newly selected expiration time is before the already pending
> scheduled report.
>
> Signed-off-by: Michal Tesar <mtesar@redhat.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Urgent Please;;
From: Dr. David White @ 2017-01-02 17:42 UTC (permalink / raw)
Dear,
With due respect to your person and much sincerity of purpose. I have a business proposal which I will like to handle with you and $14.5 Million USD is involve. But be rest assured that everything is legal and risk free as I have concluded all the arrangements and the legal papers that will back the transaction up. Kindly indicate your interest as to enable me tell you more detail of the proposal. Waiting for your urgent response.
Yours Faithfully,
Dr. David White
^ permalink raw reply
* Re: [PATCH] Update pptp handling to avoid null pointer deref. v2
From: David Miller @ 2017-01-02 17:54 UTC (permalink / raw)
To: ian.kumlien; +Cc: linux-kernel, netdev, stable
In-Reply-To: <20170102081835.25557-1-ian.kumlien@gmail.com>
From: Ian Kumlien <ian.kumlien@gmail.com>
Date: Mon, 2 Jan 2017 09:18:35 +0100
> __skb_flow_dissect can be called with a skb or a data packet, either
> can be NULL. All calls seems to have been moved to __skb_header_pointer
> except the pptp handling which is still calling skb_header_pointer.
...
> Fixes: ab10dccb1160 ("rps: Inspect PPTP encapsulated by GRE to get flow hash")
> Signed-off-by: Ian Kumlien <ian.kumlien@gmail.com>
Applied and queued up for -stable.
^ permalink raw reply
* [PATCH net] Documentation/networking: fix typo in mpls-sysctl
From: Alexander Alemayhu @ 2017-01-02 17:52 UTC (permalink / raw)
To: netdev; +Cc: corbet, Alexander Alemayhu
s/utliziation/utilization
Signed-off-by: Alexander Alemayhu <alexander@alemayhu.com>
---
Documentation/networking/mpls-sysctl.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/networking/mpls-sysctl.txt b/Documentation/networking/mpls-sysctl.txt
index 9ed15f86c17c..15d8d16934fd 100644
--- a/Documentation/networking/mpls-sysctl.txt
+++ b/Documentation/networking/mpls-sysctl.txt
@@ -5,8 +5,8 @@ platform_labels - INTEGER
possible to configure forwarding for label values equal to or
greater than the number of platform labels.
- A dense utliziation of the entries in the platform label table
- is possible and expected aas the platform labels are locally
+ A dense utilization of the entries in the platform label table
+ is possible and expected as the platform labels are locally
allocated.
If the number of platform label table entries is set to 0 no
--
2.11.0
^ permalink raw reply related
* Re: pull-request: mac80211 2017-01-02
From: David Miller @ 2017-01-02 17:28 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20170102143904.20851-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Mon, 2 Jan 2017 15:39:03 +0100
> Happy New Year :-)
Same to you :-)
> Even though I was out for around two weeks, only a single fix came in,
> I guess everyone else was also out. But if people were out, then they
> won't be sending fixes soon again I suppose, and if they weren't out
> they haven't sent more fixes, so I decided to send this one to you now.
>
> Please pull and let me know if there's any problem.
It certainly was a slow holiday break this year, kind of nice
actually...
Pulled, thanks Johannes.
^ permalink raw reply
* [PATCH 1/1] igb: Fix hw_dbg logging in igb_update_flash_i210
From: Peter Senna Tschudin @ 2017-01-02 17:26 UTC (permalink / raw)
Cc: Hannu Lounento, Peter Senna Tschudin, Jeff Kirsher,
moderated list:INTEL ETHERNET DRIVERS,
open list:NETWORKING DRIVERS, open list
From: Hannu Lounento <hannu.lounento@ge.com>
Fix an if statement with hw_dbg lines where the logic was inverted with
regards to the corresponding return value used in the if statement.
Signed-off-by: Hannu Lounento <hannu.lounento@ge.com>
Signed-off-by: Peter Senna Tschudin <peter.senna@collabora.com>
---
drivers/net/ethernet/intel/igb/e1000_i210.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/e1000_i210.c b/drivers/net/ethernet/intel/igb/e1000_i210.c
index 8aa7987..07d48f2 100644
--- a/drivers/net/ethernet/intel/igb/e1000_i210.c
+++ b/drivers/net/ethernet/intel/igb/e1000_i210.c
@@ -699,9 +699,9 @@ static s32 igb_update_flash_i210(struct e1000_hw *hw)
ret_val = igb_pool_flash_update_done_i210(hw);
if (ret_val)
- hw_dbg("Flash update complete\n");
- else
hw_dbg("Flash update time out\n");
+ else
+ hw_dbg("Flash update complete\n");
out:
return ret_val;
--
2.5.5
^ permalink raw reply related
* Re: Bug w/ (policy) routing
From: Olivier Brunel @ 2017-01-02 17:05 UTC (permalink / raw)
To: David Ahern; +Cc: netdev
In-Reply-To: <c59bcb99-39d1-3b47-7787-dd4d805eb4f6@cumulusnetworks.com>
On Mon, 2 Jan 2017 09:48:12 -0700
David Ahern <dsa@cumulusnetworks.com> wrote:
> On 1/1/17 12:52 PM, Olivier Brunel wrote:
> > Indeed, if I first delete the rule for lookup local and recreate it
> > w/ higher prio than my "lookup 50", then no more issue.
>
> After the unshare or when creating a new network namespace, bringing
> the lo device up will create the local table and the rest of the
> commands will work properly. ie., instead of moving the local rule
> you can run:
Indeed, and that's a much better solution for me, since I bring lo up
anyways, I might as well do it first. Thank you.
> unshare -n bash
>
> ip li set lo up
> ip rule add table 50 prio 50
> ip link add test type veth peer name test2
> ...
>
> -----
>
> Alex:
>
> The order of commands is influencing whether the unmerge succeeds or
> not which is wrong. I took a quick look and I don't see a simple
> solution to this. Effectively:
>
> Adding a rule before bringing up any interface does not unmerge the
> tables: $ unshare -n bash
> $ ip rule add table 50 prio 50
> $ ip li set lo up
>
> In fib_unmerge(), fib_new_table(net, RT_TABLE_LOCAL) returns null.
>
>
> Where the reverse order works:
> $ unshare -n bash
> $ ip li set lo up
> $ ip rule add table 50 prio 50
>
> David
^ permalink raw reply
* Re: Bug w/ (policy) routing
From: David Ahern @ 2017-01-02 16:48 UTC (permalink / raw)
To: Olivier Brunel; +Cc: netdev, Alexander Duyck
In-Reply-To: <20170101205238.426803f4@jjacky.com>
On 1/1/17 12:52 PM, Olivier Brunel wrote:
> Indeed, if I first delete the rule for lookup local and recreate it
> w/ higher prio than my "lookup 50", then no more issue.
After the unshare or when creating a new network namespace, bringing the lo device up will create the local table and the rest of the commands will work properly. ie., instead of moving the local rule you can run:
unshare -n bash
ip li set lo up
ip rule add table 50 prio 50
ip link add test type veth peer name test2
...
-----
Alex:
The order of commands is influencing whether the unmerge succeeds or not which is wrong. I took a quick look and I don't see a simple solution to this. Effectively:
Adding a rule before bringing up any interface does not unmerge the tables:
$ unshare -n bash
$ ip rule add table 50 prio 50
$ ip li set lo up
In fib_unmerge(), fib_new_table(net, RT_TABLE_LOCAL) returns null.
Where the reverse order works:
$ unshare -n bash
$ ip li set lo up
$ ip rule add table 50 prio 50
David
^ permalink raw reply
* [PATCH] net: emulex: benet: use new api ethtool_{get|set}_link_ksettings
From: Philippe Reynes @ 2017-01-02 16:42 UTC (permalink / raw)
To: sathya.perla, ajit.khaparde, sriharsha.basavapatna, somnath.kotur,
davem
Cc: netdev, linux-kernel, Philippe Reynes
The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.
Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
---
drivers/net/ethernet/emulex/benet/be_ethtool.c | 73 +++++++++++-------------
1 files changed, 34 insertions(+), 39 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_ethtool.c b/drivers/net/ethernet/emulex/benet/be_ethtool.c
index 0a48a31..7d1819c 100644
--- a/drivers/net/ethernet/emulex/benet/be_ethtool.c
+++ b/drivers/net/ethernet/emulex/benet/be_ethtool.c
@@ -606,7 +606,8 @@ bool be_pause_supported(struct be_adapter *adapter)
false : true;
}
-static int be_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
+static int be_get_link_ksettings(struct net_device *netdev,
+ struct ethtool_link_ksettings *cmd)
{
struct be_adapter *adapter = netdev_priv(netdev);
u8 link_status;
@@ -614,13 +615,14 @@ static int be_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
int status;
u32 auto_speeds;
u32 fixed_speeds;
+ u32 supported = 0, advertising = 0;
if (adapter->phy.link_speed < 0) {
status = be_cmd_link_status_query(adapter, &link_speed,
&link_status, 0);
if (!status)
be_link_status_update(adapter, link_status);
- ethtool_cmd_speed_set(ecmd, link_speed);
+ cmd->base.speed = link_speed;
status = be_cmd_get_phy_info(adapter);
if (!status) {
@@ -629,58 +631,51 @@ static int be_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
be_cmd_query_cable_type(adapter);
- ecmd->supported =
+ supported =
convert_to_et_setting(adapter,
auto_speeds |
fixed_speeds);
- ecmd->advertising =
+ advertising =
convert_to_et_setting(adapter, auto_speeds);
- ecmd->port = be_get_port_type(adapter);
+ cmd->base.port = be_get_port_type(adapter);
if (adapter->phy.auto_speeds_supported) {
- ecmd->supported |= SUPPORTED_Autoneg;
- ecmd->autoneg = AUTONEG_ENABLE;
- ecmd->advertising |= ADVERTISED_Autoneg;
+ supported |= SUPPORTED_Autoneg;
+ cmd->base.autoneg = AUTONEG_ENABLE;
+ advertising |= ADVERTISED_Autoneg;
}
- ecmd->supported |= SUPPORTED_Pause;
+ supported |= SUPPORTED_Pause;
if (be_pause_supported(adapter))
- ecmd->advertising |= ADVERTISED_Pause;
-
- switch (adapter->phy.interface_type) {
- case PHY_TYPE_KR_10GB:
- case PHY_TYPE_KX4_10GB:
- ecmd->transceiver = XCVR_INTERNAL;
- break;
- default:
- ecmd->transceiver = XCVR_EXTERNAL;
- break;
- }
+ advertising |= ADVERTISED_Pause;
} else {
- ecmd->port = PORT_OTHER;
- ecmd->autoneg = AUTONEG_DISABLE;
- ecmd->transceiver = XCVR_DUMMY1;
+ cmd->base.port = PORT_OTHER;
+ cmd->base.autoneg = AUTONEG_DISABLE;
}
/* Save for future use */
- adapter->phy.link_speed = ethtool_cmd_speed(ecmd);
- adapter->phy.port_type = ecmd->port;
- adapter->phy.transceiver = ecmd->transceiver;
- adapter->phy.autoneg = ecmd->autoneg;
- adapter->phy.advertising = ecmd->advertising;
- adapter->phy.supported = ecmd->supported;
+ adapter->phy.link_speed = cmd->base.speed;
+ adapter->phy.port_type = cmd->base.port;
+ adapter->phy.autoneg = cmd->base.autoneg;
+ adapter->phy.advertising = advertising;
+ adapter->phy.supported = supported;
} else {
- ethtool_cmd_speed_set(ecmd, adapter->phy.link_speed);
- ecmd->port = adapter->phy.port_type;
- ecmd->transceiver = adapter->phy.transceiver;
- ecmd->autoneg = adapter->phy.autoneg;
- ecmd->advertising = adapter->phy.advertising;
- ecmd->supported = adapter->phy.supported;
+ cmd->base.speed = adapter->phy.link_speed;
+ cmd->base.port = adapter->phy.port_type;
+ cmd->base.autoneg = adapter->phy.autoneg;
+ advertising = adapter->phy.advertising;
+ supported = adapter->phy.supported;
}
- ecmd->duplex = netif_carrier_ok(netdev) ? DUPLEX_FULL : DUPLEX_UNKNOWN;
- ecmd->phy_address = adapter->port_num;
+ cmd->base.duplex = netif_carrier_ok(netdev) ?
+ DUPLEX_FULL : DUPLEX_UNKNOWN;
+ cmd->base.phy_address = adapter->port_num;
+
+ ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.supported,
+ supported);
+ ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.advertising,
+ advertising);
return 0;
}
@@ -1399,7 +1394,6 @@ static int be_set_priv_flags(struct net_device *netdev, u32 flags)
}
const struct ethtool_ops be_ethtool_ops = {
- .get_settings = be_get_settings,
.get_drvinfo = be_get_drvinfo,
.get_wol = be_get_wol,
.set_wol = be_set_wol,
@@ -1433,5 +1427,6 @@ static int be_set_priv_flags(struct net_device *netdev, u32 flags)
.get_channels = be_get_channels,
.set_channels = be_set_channels,
.get_module_info = be_get_module_info,
- .get_module_eeprom = be_get_module_eeprom
+ .get_module_eeprom = be_get_module_eeprom,
+ .get_link_ksettings = be_get_link_ksettings,
};
--
1.7.4.4
^ permalink raw reply related
* Re: [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM.
From: Richard Cochran @ 2017-01-02 16:13 UTC (permalink / raw)
To: Nicolas Ferre
Cc: Rafal Ozieblo, Andrei Pistirica, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, davem@davemloft.net,
harinikatakamlinux@gmail.com, harini.katakam@xilinx.com,
punnaia@xilinx.com, michals@xilinx.com, anirudh@xilinx.com,
boris.brezillon@free-electrons.com,
alexandre.belloni@free-electrons.com, tbultel@pixelsurmer.com
In-Reply-To: <0717c63b-2e29-9ad1-7f01-39817980933f@atmel.com>
On Mon, Jan 02, 2017 at 03:47:07PM +0100, Nicolas Ferre wrote:
> Le 02/01/2017 à 12:31, Richard Cochran a écrit :
> > This Cadence IP core is a complete disaster.
>
> Well, it evolved and propose several options to different SoC
> integrators. This is not something unusual...
> I suspect as well that some other network adapters have the same
> weakness concerning PTP timestamp in single register as the early
> revisions of this IP.
It appears that this core can neither latch the time on read or write,
or even latch time stamps. I have worked with many different PTP HW
implementations, even early ones like on the ixp4xx, and it is no
exaggeration to say that this one is uniquely broken.
> I suspect that Rafal tend to jump too quickly to the latest IP revisions
> and add more options to this series: let's not try to pour too much
> things into this code right now.
Why can't you check the IP version in the driver?
And is it really true that the registers don't latch the time stamps,
as Rafal said? If so, then we cannot accept the non-descriptor driver
version, since it cannot possibly work correctly.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH net-next rfc 0/6] convert tc_verd to integer bitfields
From: Jamal Hadi Salim @ 2017-01-02 16:09 UTC (permalink / raw)
To: Willem de Bruijn, netdev
Cc: davem, fw, dborkman, alexei.starovoitov, Willem de Bruijn,
Roman Mashak, Hannes Frederic Sowa, Shmulik Ladkani
In-Reply-To: <1482952410-50003-1-git-send-email-willemdebruijn.kernel@gmail.com>
And a happy new year netdev.
No objections to new year resolution of slimming the skb.
But: i am still concerned about the recursion that getting rid of
some of these bits could embolden. i.e my suggestion was infact to
restore some of those bits taken away by Florian after the ingress
redirect patches from Shmulik.
The possibilities are: egress->egress, egress->ingress,
ingress->egress, ingress->ingress. The suggestion was
xmit_recursion with some skb magic would suffice.
Hannes promised around last netdevconf that he has a scheme to solve
it without using any extra skb state.
cheers,
jamal
On 16-12-28 02:13 PM, Willem de Bruijn wrote:
> From: Willem de Bruijn <willemb@google.com>
>
> The skb tc_verd field takes up two bytes but uses far fewer bits.
> Convert the remaining use cases to bitfields that fit in existing
> holes (depending on config options) and potentially save the two
> bytes in struct sk_buff.
>
> This patchset is based on an earlier set by Florian Westphal and its
> discussion (http://www.spinics.net/lists/netdev/msg329181.html).
>
> Patches 1 and 2 are low hanging fruit: removing the last traces of
> data that are no longer stored in tc_verd.
>
> Patches 3 and 4 convert tc_verd to individual bitfields (5 bits).
>
> Patch 5 reduces TC_AT to a single bitfield,
> as AT_STACK is not valid here (unlike in the case of TC_FROM).
>
> Patch 6 changes TC_FROM to two bitfields with clearly defined purpose.
>
> It may be possible to reduce storage further after this initial round.
> If tc_skip_classify is set only by IFB, testing skb_iif may suffice.
> The L2 header pushing/popping logic can perhaps be shared with
> AF_PACKET, which currently not pkt_type for the same purpose.
>
> Tested ingress mirred + netem + ifb:
>
> ip link set dev ifb0 up
> tc qdisc add dev eth0 ingress
> tc filter add dev eth0 parent ffff: \
> u32 match ip dport 8000 0xffff \
> action mirred egress redirect dev ifb0
> tc qdisc add dev ifb0 root netem delay 1000ms
> nc -u -l 8000 &
> ssh $otherhost nc -u $host 8000
>
> Tested egress mirred:
>
> ip link add veth1 type veth peer name veth2
> ip link set dev veth1 up
> ip link set dev veth2 up
> tcpdump -n -i veth2 udp and dst port 8000 &
>
> tc qdisc add dev eth0 root handle 1: prio
> tc filter add dev eth0 parent 1:0 \
> u32 match ip dport 8000 0xffff \
> action mirred egress redirect dev veth1
> tc qdisc add dev veth1 root netem delay 1000ms
> nc -u $otherhost 8000
>
> Willem de Bruijn (6):
> net-tc: remove unused tc_verd fields
> net-tc: make MAX_RECLASSIFY_LOOP local
> net-tc: extract skip classify bit from tc_verd
> net-tc: convert tc_verd to integer bitfields
> net-tc: convert tc_at to tc_at_ingress
> net-tc: convert tc_from to tc_from_ingress and tc_redirected
>
> drivers/net/ifb.c | 16 ++++-------
> drivers/staging/octeon/ethernet-tx.c | 5 ++--
> include/linux/skbuff.h | 15 ++++++----
> include/net/sch_generic.h | 20 ++++++++++++-
> include/uapi/linux/pkt_cls.h | 55 ------------------------------------
> net/core/dev.c | 20 ++++---------
> net/core/pktgen.c | 4 +--
> net/core/skbuff.c | 3 --
> net/sched/act_api.c | 8 ++----
> net/sched/act_ife.c | 7 ++---
> net/sched/act_mirred.c | 21 +++++++-------
> net/sched/sch_api.c | 4 ++-
> net/sched/sch_netem.c | 2 +-
> 13 files changed, 64 insertions(+), 116 deletions(-)
>
^ permalink raw reply
* Re: [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM.
From: Richard Cochran @ 2017-01-02 16:03 UTC (permalink / raw)
To: Harini Katakam
Cc: Rafal Ozieblo, Andrei Pistirica, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, davem@davemloft.net,
nicolas.ferre@atmel.com, harini.katakam@xilinx.com,
punnaia@xilinx.com, michals@xilinx.com, anirudh@xilinx.com,
boris.brezillon@free-electrons.com,
alexandre.belloni@free-electrons.com, tbultel@pixelsurmer.com
In-Reply-To: <CAFcVECLg-hXvfgwRW-fxi+N0k=7pTaEMhS5EMXV9_OO+xGRUqA@mail.gmail.com>
On Mon, Jan 02, 2017 at 05:13:34PM +0530, Harini Katakam wrote:
> From the revision history of Cadence spec, all versions starting
> r1p02 have ability to include timestamp in descriptors.
So why not add code to read the version, hm?
> For previous versions the event register is the only option.
And is it true that the regsiters do not latch the time stamp?
If so, then the IP core is more than useless.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH] rfkill: remove rfkill-regulator
From: Johannes Berg @ 2017-01-02 15:03 UTC (permalink / raw)
To: linux-wireless
Cc: netdev, Guiming Zhuo, Antonio Ospite, Paul Cercueil, Rob Herring,
Maarten ter Huurne
In-Reply-To: <20170102150157.26745-1-johannes@sipsolutions.net>
On Mon, 2017-01-02 at 16:01 +0100, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> There are no users of this ("vrfkill") in the tree, so it's just
> dead code - remove it.
>
> This also isn't really how rfkill is supposed to be used - it's
> intended as a signalling mechanism to/from the device, which the
> driver (and partially cfg80211) will handle - having a separate
> rfkill instance for a regulator is confusing, the driver should
> use the regulator instead to turn off the device when requested.
OTOH, the rfkill-gpio is essentially the same thing, and it *does* get
used - by ACPI even, to control a GPS chip. And I'm not even sure that
there's a clear place to put this since there probably aren't any GPS
drivers?
johannes
^ permalink raw reply
* Re: [PATCH net 0/3] net: stmmac: dwmac-oxnas: fix leaks and simplify pm
From: Neil Armstrong @ 2017-01-02 15:03 UTC (permalink / raw)
To: Johan Hovold, David S. Miller
Cc: Giuseppe Cavallaro, Alexandre Torgue, netdev, linux-oxnas,
linux-kernel
In-Reply-To: <20170102115604.32482-1-johan@kernel.org>
On 01/02/2017 12:56 PM, Johan Hovold wrote:
> These patches fixes of-node and fixed-phydev leaks in the recently added
> dwmac-oxnas driver, and ultimately switches over to using the generic pm
> implementation as the required callbacks are now in place.
>
> Note that this series has only been compile tested.
>
> Johan
>
>
> Johan Hovold (3):
> net: stmmac: dwmac-oxnas: fix of-node leak
> net: stmmac: dwmac-oxnas: fix fixed-link-phydev leaks
> net: stmmac: dwmac-oxnas: use generic pm implementation
>
> drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c | 89 +++++++++--------------
> 1 file changed, 33 insertions(+), 56 deletions(-)
>
Hi Johan,
This series looks good, I will (hopefully) send a Tested-by in the next few days.
Thanks,
Neil
^ permalink raw reply
* [PATCH] rfkill: remove rfkill-regulator
From: Johannes Berg @ 2017-01-02 15:01 UTC (permalink / raw)
To: linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Guiming Zhuo, Antonio Ospite,
Paul Cercueil, Rob Herring, Maarten ter Huurne, Johannes Berg
From: Johannes Berg <johannes.berg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
There are no users of this ("vrfkill") in the tree, so it's just
dead code - remove it.
This also isn't really how rfkill is supposed to be used - it's
intended as a signalling mechanism to/from the device, which the
driver (and partially cfg80211) will handle - having a separate
rfkill instance for a regulator is confusing, the driver should
use the regulator instead to turn off the device when requested.
Signed-off-by: Johannes Berg <johannes.berg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
include/linux/rfkill-regulator.h | 48 ------------
net/rfkill/Kconfig | 11 ---
net/rfkill/Makefile | 1 -
net/rfkill/rfkill-regulator.c | 154 ---------------------------------------
4 files changed, 214 deletions(-)
delete mode 100644 include/linux/rfkill-regulator.h
delete mode 100644 net/rfkill/rfkill-regulator.c
diff --git a/include/linux/rfkill-regulator.h b/include/linux/rfkill-regulator.h
deleted file mode 100644
index aca36bc83315..000000000000
--- a/include/linux/rfkill-regulator.h
+++ /dev/null
@@ -1,48 +0,0 @@
-/*
- * rfkill-regulator.c - Regulator consumer driver for rfkill
- *
- * Copyright (C) 2009 Guiming Zhuo <gmzhuo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
- * Copyright (C) 2011 Antonio Ospite <ospite-aNJ+ML1ZbiP93QAQaVx+gl6hYfS7NtTn@public.gmane.org>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- */
-
-#ifndef __LINUX_RFKILL_REGULATOR_H
-#define __LINUX_RFKILL_REGULATOR_H
-
-/*
- * Use "vrfkill" as supply id when declaring the regulator consumer:
- *
- * static struct regulator_consumer_supply pcap_regulator_V6_consumers [] = {
- * { .dev_name = "rfkill-regulator.0", .supply = "vrfkill" },
- * };
- *
- * If you have several regulator driven rfkill, you can append a numerical id to
- * .dev_name as done above, and use the same id when declaring the platform
- * device:
- *
- * static struct rfkill_regulator_platform_data ezx_rfkill_bt_data = {
- * .name = "ezx-bluetooth",
- * .type = RFKILL_TYPE_BLUETOOTH,
- * };
- *
- * static struct platform_device a910_rfkill = {
- * .name = "rfkill-regulator",
- * .id = 0,
- * .dev = {
- * .platform_data = &ezx_rfkill_bt_data,
- * },
- * };
- */
-
-#include <linux/rfkill.h>
-
-struct rfkill_regulator_platform_data {
- char *name; /* the name for the rfkill switch */
- enum rfkill_type type; /* the type as specified in rfkill.h */
-};
-
-#endif /* __LINUX_RFKILL_REGULATOR_H */
diff --git a/net/rfkill/Kconfig b/net/rfkill/Kconfig
index 868f1ad0415a..060600b03fad 100644
--- a/net/rfkill/Kconfig
+++ b/net/rfkill/Kconfig
@@ -23,17 +23,6 @@ config RFKILL_INPUT
depends on INPUT = y || RFKILL = INPUT
default y if !EXPERT
-config RFKILL_REGULATOR
- tristate "Generic rfkill regulator driver"
- depends on RFKILL || !RFKILL
- depends on REGULATOR
- help
- This options enable controlling radio transmitters connected to
- voltage regulator using the regulator framework.
-
- To compile this driver as a module, choose M here: the module will
- be called rfkill-regulator.
-
config RFKILL_GPIO
tristate "GPIO RFKILL driver"
depends on RFKILL
diff --git a/net/rfkill/Makefile b/net/rfkill/Makefile
index 311768783f4a..87a80aded0b3 100644
--- a/net/rfkill/Makefile
+++ b/net/rfkill/Makefile
@@ -5,5 +5,4 @@
rfkill-y += core.o
rfkill-$(CONFIG_RFKILL_INPUT) += input.o
obj-$(CONFIG_RFKILL) += rfkill.o
-obj-$(CONFIG_RFKILL_REGULATOR) += rfkill-regulator.o
obj-$(CONFIG_RFKILL_GPIO) += rfkill-gpio.o
diff --git a/net/rfkill/rfkill-regulator.c b/net/rfkill/rfkill-regulator.c
deleted file mode 100644
index 50cd26a48e87..000000000000
--- a/net/rfkill/rfkill-regulator.c
+++ /dev/null
@@ -1,154 +0,0 @@
-/*
- * rfkill-regulator.c - Regulator consumer driver for rfkill
- *
- * Copyright (C) 2009 Guiming Zhuo <gmzhuo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
- * Copyright (C) 2011 Antonio Ospite <ospite-aNJ+ML1ZbiP93QAQaVx+gl6hYfS7NtTn@public.gmane.org>
- *
- * Implementation inspired by leds-regulator driver.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- */
-
-#include <linux/module.h>
-#include <linux/err.h>
-#include <linux/slab.h>
-#include <linux/platform_device.h>
-#include <linux/regulator/consumer.h>
-#include <linux/rfkill.h>
-#include <linux/rfkill-regulator.h>
-
-struct rfkill_regulator_data {
- struct rfkill *rf_kill;
- bool reg_enabled;
-
- struct regulator *vcc;
-};
-
-static int rfkill_regulator_set_block(void *data, bool blocked)
-{
- struct rfkill_regulator_data *rfkill_data = data;
- int ret = 0;
-
- pr_debug("%s: blocked: %d\n", __func__, blocked);
-
- if (blocked) {
- if (rfkill_data->reg_enabled) {
- regulator_disable(rfkill_data->vcc);
- rfkill_data->reg_enabled = false;
- }
- } else {
- if (!rfkill_data->reg_enabled) {
- ret = regulator_enable(rfkill_data->vcc);
- if (!ret)
- rfkill_data->reg_enabled = true;
- }
- }
-
- pr_debug("%s: regulator_is_enabled after set_block: %d\n", __func__,
- regulator_is_enabled(rfkill_data->vcc));
-
- return ret;
-}
-
-static struct rfkill_ops rfkill_regulator_ops = {
- .set_block = rfkill_regulator_set_block,
-};
-
-static int rfkill_regulator_probe(struct platform_device *pdev)
-{
- struct rfkill_regulator_platform_data *pdata = pdev->dev.platform_data;
- struct rfkill_regulator_data *rfkill_data;
- struct regulator *vcc;
- struct rfkill *rf_kill;
- int ret = 0;
-
- if (pdata == NULL) {
- dev_err(&pdev->dev, "no platform data\n");
- return -ENODEV;
- }
-
- if (pdata->name == NULL || pdata->type == 0) {
- dev_err(&pdev->dev, "invalid name or type in platform data\n");
- return -EINVAL;
- }
-
- vcc = regulator_get_exclusive(&pdev->dev, "vrfkill");
- if (IS_ERR(vcc)) {
- dev_err(&pdev->dev, "Cannot get vcc for %s\n", pdata->name);
- ret = PTR_ERR(vcc);
- goto out;
- }
-
- rfkill_data = kzalloc(sizeof(*rfkill_data), GFP_KERNEL);
- if (rfkill_data == NULL) {
- ret = -ENOMEM;
- goto err_data_alloc;
- }
-
- rf_kill = rfkill_alloc(pdata->name, &pdev->dev,
- pdata->type,
- &rfkill_regulator_ops, rfkill_data);
- if (rf_kill == NULL) {
- ret = -ENOMEM;
- goto err_rfkill_alloc;
- }
-
- if (regulator_is_enabled(vcc)) {
- dev_dbg(&pdev->dev, "Regulator already enabled\n");
- rfkill_data->reg_enabled = true;
- }
- rfkill_data->vcc = vcc;
- rfkill_data->rf_kill = rf_kill;
-
- ret = rfkill_register(rf_kill);
- if (ret) {
- dev_err(&pdev->dev, "Cannot register rfkill device\n");
- goto err_rfkill_register;
- }
-
- platform_set_drvdata(pdev, rfkill_data);
- dev_info(&pdev->dev, "%s initialized\n", pdata->name);
-
- return 0;
-
-err_rfkill_register:
- rfkill_destroy(rf_kill);
-err_rfkill_alloc:
- kfree(rfkill_data);
-err_data_alloc:
- regulator_put(vcc);
-out:
- return ret;
-}
-
-static int rfkill_regulator_remove(struct platform_device *pdev)
-{
- struct rfkill_regulator_data *rfkill_data = platform_get_drvdata(pdev);
- struct rfkill *rf_kill = rfkill_data->rf_kill;
-
- rfkill_unregister(rf_kill);
- rfkill_destroy(rf_kill);
- regulator_put(rfkill_data->vcc);
- kfree(rfkill_data);
-
- return 0;
-}
-
-static struct platform_driver rfkill_regulator_driver = {
- .probe = rfkill_regulator_probe,
- .remove = rfkill_regulator_remove,
- .driver = {
- .name = "rfkill-regulator",
- },
-};
-
-module_platform_driver(rfkill_regulator_driver);
^ permalink raw reply related
* Re: [PATCH net-next] net/sched: cls_flower: Add user specified data
From: Jamal Hadi Salim @ 2017-01-02 14:59 UTC (permalink / raw)
To: Paul Blakey, David S. Miller, netdev
Cc: Jiri Pirko, Hadar Hen Zion, Or Gerlitz, Roi Dayan, Roman Mashak
In-Reply-To: <1483362833-52114-1-git-send-email-paulb@mellanox.com>
We have been using a cookie as well for actions (which we have been
using but have been too lazy to submit so far). I am going to port
it over to the newer kernels and post it.
In our case that is intended to be opaque to the kernel i.e kernel
never inteprets it; in that case it is similar to the kernel
FIB protocol field.
In your case - could this cookie have been a class/flowid
(a 32 bit)?
And would it not make more sense for it the cookie to be
generic to all classifiers? i.e why is it specific to flower?
cheers,
jamal
On 17-01-02 08:13 AM, Paul Blakey wrote:
> This is to support saving extra data that might be helpful on retrieval.
> First use case is upcoming openvswitch flow offloads, extra data will
> include UFID and port mappings for each added flow.
>
> Signed-off-by: Paul Blakey <paulb@mellanox.com>
> Reviewed-by: Roi Dayan <roid@mellanox.com>
> Acked-by: Jiri Pirko <jiri@mellanox.com>
> ---
> include/uapi/linux/pkt_cls.h | 3 +++
> net/sched/cls_flower.c | 22 +++++++++++++++++++++-
> 2 files changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
> index cb4bcdc..ca9bbe3 100644
> --- a/include/uapi/linux/pkt_cls.h
> +++ b/include/uapi/linux/pkt_cls.h
> @@ -471,10 +471,13 @@ enum {
> TCA_FLOWER_KEY_ICMPV6_TYPE, /* u8 */
> TCA_FLOWER_KEY_ICMPV6_TYPE_MASK,/* u8 */
>
> + TCA_FLOWER_COOKIE, /* binary */
> +
> __TCA_FLOWER_MAX,
> };
>
> #define TCA_FLOWER_MAX (__TCA_FLOWER_MAX - 1)
> +#define FLOWER_MAX_COOKIE_SIZE 128
>
> enum {
> TCA_FLOWER_KEY_FLAGS_IS_FRAGMENT = (1 << 0),
> diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
> index 333f8e2..e2f5b25 100644
> --- a/net/sched/cls_flower.c
> +++ b/net/sched/cls_flower.c
> @@ -85,6 +85,8 @@ struct cls_fl_filter {
> struct rcu_head rcu;
> struct tc_to_netdev tc;
> struct net_device *hw_dev;
> + size_t cookie_len;
> + long cookie[0];
> };
>
> static unsigned short int fl_mask_range(const struct fl_flow_mask *mask)
> @@ -794,6 +796,9 @@ static int fl_change(struct net *net, struct sk_buff *in_skb,
> struct cls_fl_filter *fnew;
> struct nlattr *tb[TCA_FLOWER_MAX + 1];
> struct fl_flow_mask mask = {};
> + const struct nlattr *attr;
> + size_t cookie_len = 0;
> + void *cookie;
> int err;
>
> if (!tca[TCA_OPTIONS])
> @@ -806,10 +811,22 @@ static int fl_change(struct net *net, struct sk_buff *in_skb,
> if (fold && handle && fold->handle != handle)
> return -EINVAL;
>
> - fnew = kzalloc(sizeof(*fnew), GFP_KERNEL);
> + if (tb[TCA_FLOWER_COOKIE]) {
> + attr = tb[TCA_FLOWER_COOKIE];
> + cookie_len = nla_len(attr);
> + cookie = nla_data(attr);
> + if (cookie_len > FLOWER_MAX_COOKIE_SIZE)
> + return -EINVAL;
> + }
> +
> + fnew = kzalloc(sizeof(*fnew) + cookie_len, GFP_KERNEL);
> if (!fnew)
> return -ENOBUFS;
>
> + fnew->cookie_len = cookie_len;
> + if (cookie_len)
> + memcpy(fnew->cookie, cookie, cookie_len);
> +
> err = tcf_exts_init(&fnew->exts, TCA_FLOWER_ACT, 0);
> if (err < 0)
> goto errout;
> @@ -1151,6 +1168,9 @@ static int fl_dump(struct net *net, struct tcf_proto *tp, unsigned long fh,
>
> nla_put_u32(skb, TCA_FLOWER_FLAGS, f->flags);
>
> + if (f->cookie_len)
> + nla_put(skb, TCA_FLOWER_COOKIE, f->cookie_len, f->cookie);
> +
> if (tcf_exts_dump(skb, &f->exts))
> goto nla_put_failure;
>
>
^ permalink raw reply
* Re: [PATCH 1/2] Documentation: devicetree: Add bindings info for rfkill-regulator
From: Johannes Berg @ 2017-01-02 14:57 UTC (permalink / raw)
To: Rob Herring, Paul Cercueil
Cc: David S . Miller, Mark Rutland, netdev, devicetree, linux-kernel,
linux-wireless, Maarten ter Huurne
In-Reply-To: <20161109182612.i4rnsdxulk5ghemz@rob-hp-laptop>
> My understanding is it is generally felt that using the regulator
> enable GPIO commonly found on WiFi chips for rfkill is an abuse of
> rfkill as it is more that just an RF disable. From a DT standpoint,
> this seems like creating a binding for what a Linux driver wants.
> Instead, I think this should be either a GPIO or GPIO regulator and
> the driver for the WiFi chip should decide whether or not to register
> that as an rfkill driver.
Sadly, there are two ways to use rfkill right now:
1) the more common, and correct, way of having rfkill be a control tied
to a specific wireless interface (wifi, BT, FM, GPS, NFC, ...), to both
report the hardware button state that might be tied to it, and to
control - centrally - the software state.
2) the platform way, which some ACPI based platforms do, which register
an rfkill instance, which often allows controlling in software the
hardware line that then toggles the hardware rfkill on the WiFi NIC.
It's not clear to me what this patch is trying to achieve. It seems a
bit like something else entirely, which would be using it to toggle the
power for a wifi device? I agree that doesn't seem appropriate, and
instead the driver could bind to the regulator and disable it when wifi
gets disabled (by rfkill or simply by taking all interfaces down.)
In fact, given that there are no in-tree users, I'm tempted to remove
the rfkill-regulator entirely. Thoughts?
johannes
^ permalink raw reply
* Re: [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM.
From: Nicolas Ferre @ 2017-01-02 14:47 UTC (permalink / raw)
To: Richard Cochran, Rafal Ozieblo
Cc: Andrei Pistirica, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, davem@davemloft.net,
harinikatakamlinux@gmail.com, harini.katakam@xilinx.com,
punnaia@xilinx.com, michals@xilinx.com, anirudh@xilinx.com,
boris.brezillon@free-electrons.com,
alexandre.belloni@free-electrons.com, tbultel@pixelsurmer.com
In-Reply-To: <20170102113155.GA16373@localhost.localdomain>
Le 02/01/2017 à 12:31, Richard Cochran a écrit :
> On Mon, Jan 02, 2017 at 09:36:10AM +0000, Rafal Ozieblo wrote:
>> According Cadence Hardware team:
>> "It is just that some customers prefer to have the time in the descriptors as that is provided per frame.
>> The registers are simply overwritten when a new event frame is transmitted/received and so software could miss it."
>> The question is are you sure that you read timestamp for current frame? (not for the next frame).
>
> AFAICT, having the time stamp in the descriptor is not universally
> supported. Looking at the Xilinx Zynq 7000 TRM, I can't find any
> mention of this.
This is why I proposed to address options incrementally: without
timestamp support in descriptor (this patch series), then adding this
feature in another patch series.
Rafal, this is why Andrei noted that the case covered by this series is
not adapted to GEM-GXL and doesn't address the "timestamp in descriptor"
case.
> This Cadence IP core is a complete disaster.
Well, it evolved and propose several options to different SoC
integrators. This is not something unusual...
I suspect as well that some other network adapters have the same
weakness concerning PTP timestamp in single register as the early
revisions of this IP.
> Unless someone can tell us how this IP works in all of its
> incarnations, this series is going nowhere.
We're already as v4 (thanks to your fruitful contributions BTW) for this
series and will try to add features for other IP options & revisions
incrementally.
I suspect that Rafal tend to jump too quickly to the latest IP revisions
and add more options to this series: let's not try to pour too much
things into this code right now.
FYI, Andrei will be back online next week.
Regards,
--
Nicolas Ferre
^ permalink raw reply
* pull-request: mac80211 2017-01-02
From: Johannes Berg @ 2017-01-02 14:39 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
Happy New Year :-)
Even though I was out for around two weeks, only a single fix came in,
I guess everyone else was also out. But if people were out, then they
won't be sending fixes soon again I suppose, and if they weren't out
they haven't sent more fixes, so I decided to send this one to you now.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit eb7903bb83cc1db31a9124d4cc8a1bddebe26e33:
Merge branch 'l2tp-socket-lookup-fixes' (2017-01-01 22:07:25 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2017-01-02
for you to fetch changes up to 35f432a03e41d3bf08c51ede917f94e2288fbe8c:
mac80211: initialize fast-xmit 'info' later (2017-01-02 11:28:25 +0100)
----------------------------------------------------------------
A single fix to avoid loading an skb->cb pointer too early.
----------------------------------------------------------------
Johannes Berg (1):
mac80211: initialize fast-xmit 'info' later
net/mac80211/tx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
^ permalink raw reply
* ATENCIÓN;
From: administrador @ 2017-01-02 13:56 UTC (permalink / raw)
To: Recipients
ATENCIÓN;
Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser capaz de enviar o recibir correo nuevo hasta que vuelva a validar su buzón de correo electrónico. Para revalidar su buzón de correo, envíe la siguiente información a continuación:
nombre:
Nombre de usuario:
contraseña:
Confirmar contraseña:
E-mail:
teléfono:
Si usted no puede revalidar su buzón, el buzón se deshabilitará!
Disculpa las molestias.
Código de verificación: es: 006524
Correo Soporte Técnico © 2016
¡gracias
Sistemas administrador
^ permalink raw reply
* Re: [PATCH net-next 22/27] sctp: add rfc6525 section 5.2.4
From: Xin Long @ 2017-01-02 13:43 UTC (permalink / raw)
To: David Miller
Cc: kbuild test robot, kbuild-all, network dev, linux-sctp,
Marcelo Ricardo Leitner, Neil Horman
In-Reply-To: <20170101.113213.663892510185061837.davem@davemloft.net>
On Mon, Jan 2, 2017 at 12:32 AM, David Miller <davem@davemloft.net> wrote:
> From: Xin Long <lucien.xin@gmail.com>
> Date: Sun, 1 Jan 2017 21:26:47 +0800
>
>> As only when the result is not performed, initial_tsn variables is
>> uninitialized, peer side would ignore this value, so here is also
>> safe.
>
> It doesn't matter if it is "safe" or not, you must fix all of the
> warnings reported by kbuild before your patches will be considered
> for applying.
will fix it in next post. thanks
^ permalink raw reply
* Re: [PATCH net-next 00/27] sctp: implement rfc6525 sctp stream reconf
From: Xin Long @ 2017-01-02 13:42 UTC (permalink / raw)
To: David Miller
Cc: network dev, linux-sctp, Marcelo Ricardo Leitner, Neil Horman
In-Reply-To: <20170101.113028.1917890848811412528.davem@davemloft.net>
On Mon, Jan 2, 2017 at 12:30 AM, David Miller <davem@davemloft.net> wrote:
>
> I'm sorry but this is way too many patches to submit at one time.
>
> Split your series into smaller, more reasonably sized, groups
> of changes.
okay, will split and repost
^ permalink raw reply
* [PATCH - resubmit] igmp: Make igmp group member RFC 3376 compliant
From: Michal Tesar @ 2017-01-02 13:38 UTC (permalink / raw)
To: davem; +Cc: haliu, kuznet, jmorris, kaber, netdev
5.2. Action on Reception of a Query
When a system receives a Query, it does not respond immediately.
Instead, it delays its response by a random amount of time, bounded
by the Max Resp Time value derived from the Max Resp Code in the
received Query message. A system may receive a variety of Queries on
different interfaces and of different kinds (e.g., General Queries,
Group-Specific Queries, and Group-and-Source-Specific Queries), each
of which may require its own delayed response.
Before scheduling a response to a Query, the system must first
consider previously scheduled pending responses and in many cases
schedule a combined response. Therefore, the system must be able to
maintain the following state:
o A timer per interface for scheduling responses to General Queries.
o A per-group and interface timer for scheduling responses to Group-
Specific and Group-and-Source-Specific Queries.
o A per-group and interface list of sources to be reported in the
response to a Group-and-Source-Specific Query.
When a new Query with the Router-Alert option arrives on an
interface, provided the system has state to report, a delay for a
response is randomly selected in the range (0, [Max Resp Time]) where
Max Resp Time is derived from Max Resp Code in the received Query
message. The following rules are then used to determine if a Report
needs to be scheduled and the type of Report to schedule. The rules
are considered in order and only the first matching rule is applied.
1. If there is a pending response to a previous General Query
scheduled sooner than the selected delay, no additional response
needs to be scheduled.
2. If the received Query is a General Query, the interface timer is
used to schedule a response to the General Query after the
selected delay. Any previously pending response to a General
Query is canceled.
--8<--
Currently the timer is rearmed with new random expiration time for
every incoming query regardless of possibly already pending report.
Which is not aligned with the above RFE.
It also might happen that higher rate of incoming queries can
postpone the report after the expiration time of the first query
causing group membership loss.
Now the per interface general query timer is rearmed only
when there is no pending report already scheduled on that interface or
the newly selected expiration time is before the already pending
scheduled report.
Signed-off-by: Michal Tesar <mtesar@redhat.com>
---
net/ipv4/igmp.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index 606cc3e..5fc3fd4 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -219,9 +219,14 @@ static void igmp_start_timer(struct ip_mc_list *im, int max_delay)
static void igmp_gq_start_timer(struct in_device *in_dev)
{
int tv = prandom_u32() % in_dev->mr_maxdelay;
+ unsigned long exp = jiffies + tv + 2;
+
+ if (in_dev->mr_gq_running &&
+ time_after_eq(exp, (in_dev->mr_gq_timer).expires))
+ return;
in_dev->mr_gq_running = 1;
- if (!mod_timer(&in_dev->mr_gq_timer, jiffies+tv+2))
+ if (!mod_timer(&in_dev->mr_gq_timer, exp))
in_dev_hold(in_dev);
}
--
2.5.5
^ 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