* RE: [PATCH 0/6] Add CPTS PTP driver support
From: N, Mugunthan V @ 2012-10-22 10:51 UTC (permalink / raw)
To: Richard Cochran; +Cc: netdev@vger.kernel.org, davem@davemloft.net
In-Reply-To: <20121021184617.GA32627@netboy.at.omicron.at>
> -----Original Message-----
> From: Richard Cochran [mailto:richardcochran@gmail.com]
> Sent: Monday, October 22, 2012 12:16 AM
> To: N, Mugunthan V
> Cc: netdev@vger.kernel.org; davem@davemloft.net
> Subject: Re: [PATCH 0/6] Add CPTS PTP driver support
>
> On Wed, Oct 17, 2012 at 04:15:12AM +0530, Mugunthan V N wrote:
> > This patch series contains driver implementation for TI Common
> Platform
> > Time Sync (CPTS) driver for PTP packet timestamping.
> >
> > CPTS is found in following TI SoC.
> > * AM335X - http://www.ti.com/litv/pdf/spruh73c
> > * DM814X - http://www.ti.com/litv/pdf/sprugz8
> >
> > The Common Platform Time Sync (CPTS) module is used to facilitate
> host
> > control of time sync operations. It enables compliance with the IEEE
> 1588-2008
> > standard for a precision clock synchronization protocol
> >
> > This patch series is tested over vanilla kernel with the below
> patches
> > http://marc.info/?l=linux-arm-kernel&m=135032863723906&w=2
>
> I tried v3.7-rc1 plus those patches, plus this patch series, plus the
> small addition of this ...
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi
> b/arch/arm/boot/dts/am33xx.dtsi
> index f6bea04..e0e152b 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -222,6 +222,7 @@
> ale_entries = <1024>;
> host_port_reg_ofs = <0x108>;
> hw_stats_reg_ofs = <0x900>;
> + cpts_reg_ofs = <0xc00>;
> bd_ram_ofs = <0x2000>;
> bd_ram_size = <0x2000>;
> no_bd_ram = <0>;
>
>
> ... and it doesn't work.
>
> > Tested both L2 and L4 PTP packet timestamping
>
> Really?
>
> With your driver I could not get either L2 or L4 time stamps to
> appear. At this point, my own driver is working a lot better, and so
> this just adds another reason to favor my driver, in addtion to the
> points I mentioned in my other post.
>
Richard
The following patch n eeds to be used to test the CPTS driver.
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index f6bea04..cd9b3b4 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -238,13 +238,13 @@
interrupts = <40 41 42 43>;
ranges;
cpsw_emac0: slave@0 {
- slave_reg_ofs = <0x208>;
+ slave_reg_ofs = <0x200>;
sliver_reg_ofs = <0xd80>;
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
cpsw_emac1: slave@1 {
- slave_reg_ofs = <0x308>;
+ slave_reg_ofs = <0x300>;
sliver_reg_ofs = <0xdc0>;
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
I have not added the above two patches in the patch series as the main
CPSW DT file patch is not accepted and not available in netdev git tree.
I have planned to post the patch series to DT mailing list soon after
the driver is accepted.
Sorry for not mentioning the same in the patch series
Regards
Mugunthan V N
^ permalink raw reply related
* Re: [GIT PULL nf-next] IPVS for 3.7 #2
From: Pablo Neira Ayuso @ 2012-10-22 10:55 UTC (permalink / raw)
To: Simon Horman
Cc: lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Julian Anastasov, Hans Schillstrom, Hans Schillstrom,
Jesper Dangaard Brouer
In-Reply-To: <1348800904-23902-1-git-send-email-horms@verge.net.au>
Hi Simon, Jesper,
On Fri, Sep 28, 2012 at 11:54:57AM +0900, Simon Horman wrote:
> Hi Pablo,
>
> please consider the following enhancements to IPVS for inclusion in 3.7.
>
> ----------------------------------------------------------------
> The following changes since commit 82c93fcc2e1737fede2752520f1bf8f4de6304d8:
>
> x86: bpf_jit_comp: add XOR instruction for BPF JIT (2012-09-24 16:54:35 -0400)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs-next.git master
I've pulled this now that net-next is back open.
Please, next time re-submit again if you miss the merge window.
BTW, I expect one follow-up patch to move ipv6_find_hdr to
net/ipv6/netfilter.c (so you don't need to depend on ip6_tables for
just one single function).
Thanks a lot!
^ permalink raw reply
* RE: [PATCH 5/6] drivers: net: ethernet: cpts: implement cpts hardware clock
From: N, Mugunthan V @ 2012-10-22 10:55 UTC (permalink / raw)
To: Richard Cochran; +Cc: netdev@vger.kernel.org, davem@davemloft.net
In-Reply-To: <20121020134331.GA5444@netboy.at.omicron.at>
> -----Original Message-----
> From: Richard Cochran [mailto:richardcochran@gmail.com]
> Sent: Saturday, October 20, 2012 7:14 PM
> To: N, Mugunthan V
> Cc: netdev@vger.kernel.org; davem@davemloft.net
> Subject: Re: [PATCH 5/6] drivers: net: ethernet: cpts: implement cpts
> hardware clock
>
>
> I did a careful read of this driver, and I found a number of issues,
> but I am not giving a line by line review, for reasons explained
> below. For the most part, your driver is very similar to mine, and
> your driver would probably work fine too, when given a bit of review
> and revision. However, in the end, it would end up looking nearly
> identical to mine.
>
> The issues about which you have voiced concern (counter roll over,
> changing input clock frequency) are by no means unique to the CPTS.
> The existing PHC drivers all handle these issues in a way consistent
> with each other. New drivers should not invent their own solutions to
> such problems.
>
> If I had never written a CPTS driver and had seen your present
> submission first, then I would be willing to help you get your driver
> merged. But in my view, this work is already done, and so I am favoring
> my own driver at this point.
>
> Here is my suggestion for moving forward with support the CPTS:
>
> - It is too early to support the CPTS v1 found on the DM81xx, since
> the CPSW support (including DT) is totally lacking. Judging from
> your present driver and the TRM, the differences are minimal and
> will be easy to add later on. For now, we can simply check the
> version register for v2.
>
> - If you can get the patches needed to get the CPSW working merged
> during the present v3.7-rc interval, that would form a basis for
> getting the CPTS into v3.8. I tried to post the patches that I had
> collected, but I failed to get them all accepted. I really don't
> know the issues surrounding those patches at all, and so I would
> appreciate if you would take the lead and get this support merged.
>
> - I will add a version check for CPTS v2 and integrate your CPSW
> multicast patch (and anything else you think is missing) into my own
> patch series. Once your background patches have appeared, I will
> post the CPTS series for net-next, in time for v3.8.
The CPTS found in DM81XX and AM335X is of same version, only the CPSW version
is different in both SoCs.
Regards
Mugunthan V N
>
> - Looking ahead, once you get a patch series to fully support the
> DM81xx CPSW, we can patch the CPTS too.
>
> Thanks,
> Richard
^ permalink raw reply
* Re: [PATCH V2 0/7] support the cpts found on am335x devices
From: Richard Cochran @ 2012-10-22 11:02 UTC (permalink / raw)
To: N, Mugunthan V
Cc: netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
David Miller, Chemparathy, Cyril, Govindarajan, Sriramakrishnan
In-Reply-To: <EB1619762EAF8B4E97A227FB77B7E0293E9FD697@DBDE01.ent.ti.com>
On Mon, Oct 22, 2012 at 10:39:40AM +0000, N, Mugunthan V wrote:
>
> I think the timecounter_init initializes only the software. But still I am
> not clear how the time given in cpts_ptp_settime will be projected to
> hardware. Can you correct me if I am wrong.
Look at the settime function:
+static int cpts_ptp_settime(struct ptp_clock_info *ptp,
+ const struct timespec *ts)
+{
+ u64 ns;
+ unsigned long flags;
+ struct cpts *cpts = container_of(ptp, struct cpts, info);
+
+ ns = ts->tv_sec * 1000000000ULL;
+ ns += ts->tv_nsec;
+
+ spin_lock_irqsave(&cpts->lock, flags);
+ timecounter_init(&cpts->tc, &cpts->cc, ns);
+ spin_unlock_irqrestore(&cpts->lock, flags);
+
+ return 0;
+}
Then, look at the implementation of timecounter_init().
> > > Since we poll for the 32bit over flow for every HZ * 8 cycle, won't
> > > there be a system overhead. If the CPTS ref clock is changed
> > according
> > > to the ptp freq adjust api, how will the timecounter take care of
> > change
> > > in frequency
> >
> > There is nothing to do here. What are you asking?
>
> I think instead of fixing the driver to AM335X, let's make the driver
> generic as the same driver can be used to TI814X, TI813X and other
> upcoming platforms TI811X where the CPTS ref clock can be changed as
> per usage requirement.
Now I see what your are worried about, but it really isn't a big
problem. The solution in your driver of doing a 64 bit division in the
hot path is unattractive and unnecessary. We can accomodate variable
reference clock frequencies using a board specific DT, just as we do
for gianfar today.
Let's just get the am335x working, shall we? Until we actually have
the other boards working, all this talk about TI81xx is really just
talk. I mean, ATM the CPSW does not work on *any* board at all.
> > I hope that you meant, "better if we can configure _either_ slave."
> > Considering how SO_TIMESTAMPING works, you can't use both at once.
> >
>
> Since CPSW as a Ethernet switch, the PTP packet can be delivered to
> any downstream port. So if we fix the PTP time stamping to one port
> then the driver won't receive time stamping information when the packet
> is delivered to the other port.
And just how is this supposed to work with SO_TIMESTAMPING?
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH 1/6] drivers: net: ethernet: cpsw: add support for CPSW register offset changes in different IP version
From: Richard Cochran @ 2012-10-22 11:23 UTC (permalink / raw)
To: N, Mugunthan V; +Cc: netdev@vger.kernel.org, davem@davemloft.net
In-Reply-To: <EB1619762EAF8B4E97A227FB77B7E0293E9FD69E@DBDE01.ent.ti.com>
On Mon, Oct 22, 2012 at 10:39:51AM +0000, N, Mugunthan V wrote:
> > This is wasting memory with unused static stables. There is a better
> > way to handle this issue.
>
> I have taken the code reference from the following driver.
> drivers/i2c/busses/i2c-omap.c
Can't speak for that driver.
BTW the ALE driver is also horribly wasting space with the "struct
ale_control_info ale_controls[ALE_NUM_CONTROLS]" thing.
> Can you refer other better solution to handle this?
Yes, I can think of two different ways. Maybe you can think of yet
other ways.
1. For those few registers that are not aligned the same way but have
the same bit layout (and you actually use in the driver), keep a
separate pointer in your driver's private struct.
2. Make two different declarations of structs corresponding to two
register layouts and use a cast in the access function based on
version.
I object to the tables of offsets because these take up twice the
memory of the registers themselves, even if you don't use all of the
registers.
> > You didn't provide a way to even use this code, like a dts for a
> > non-am335x board with the older version.
> >
> > I think it would be better to start off supporting one version and
> > have that fully working, and then add the older version, but *really*
> > add it so that it is actually working.
> >
>
> Since version info from hardware registers can be used to differentiate between
> the CPSW versions so I don't think there is a need to provide the same through DT.
I did not say to put the versions into the DT.
What I meant was that there is no need to add code that tests the
version and acts differently, if there are no users of the special
cases.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH 2/6] drivers: net: ethernet: davinci_cpdma: add clear api for statistics interrupt
From: Richard Cochran @ 2012-10-22 11:31 UTC (permalink / raw)
To: N, Mugunthan V; +Cc: netdev@vger.kernel.org, davem@davemloft.net
In-Reply-To: <EB1619762EAF8B4E97A227FB77B7E0293E9FD6BB@DBDE01.ent.ti.com>
On Mon, Oct 22, 2012 at 10:42:26AM +0000, N, Mugunthan V wrote:
>
> What happens when Hardware timestamps are used?
They are not being used.
> It will be good to
> notify the application immediately using the interrupts instead of
> using workqueue which can delay the event in hardware for max about
> HZ*8.
Yes, it would make sense to use the interrupt in that case, but I did
not see any code supporting external events. In any case, I still want
to handle the overflow in the same way as in the other PHC drivers,
for the sake of consistency, and to avoid wasting CPU time "in
interrupt" with silly counter overflow code.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH 4/6] ptp: add api to get ptp seq id and event type from skb
From: Richard Cochran @ 2012-10-22 11:36 UTC (permalink / raw)
To: N, Mugunthan V; +Cc: netdev@vger.kernel.org, davem@davemloft.net
In-Reply-To: <EB1619762EAF8B4E97A227FB77B7E0293E9FD6E6@DBDE01.ent.ti.com>
On Mon, Oct 22, 2012 at 10:46:50AM +0000, N, Mugunthan V wrote:
>
> Yeah agreed on static function too long, but this can be kept inside PTP
> frame work as every driver needs to use this API to parse the PTP events
> from the skb.
No, not every driver need this code. Otherwise it would already exist
in every driver.
Although some of the hardware does provide packet metadata for
matching time stamps to payloads, each hardware that I know of has its
own subtle differences in this regard.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH 5/6] drivers: net: ethernet: cpts: implement cpts hardware clock
From: Richard Cochran @ 2012-10-22 11:41 UTC (permalink / raw)
To: N, Mugunthan V; +Cc: netdev@vger.kernel.org, davem@davemloft.net
In-Reply-To: <EB1619762EAF8B4E97A227FB77B7E0293E9FD709@DBDE01.ent.ti.com>
On Mon, Oct 22, 2012 at 10:55:55AM +0000, N, Mugunthan V wrote:
> > - I will add a version check for CPTS v2 and integrate your CPSW
> > multicast patch (and anything else you think is missing) into my own
> > patch series. Once your background patches have appeared, I will
> > post the CPTS series for net-next, in time for v3.8.
>
> The CPTS found in DM81XX and AM335X is of same version, only the CPSW version
> is different in both SoCs.
Okay, good, so we can keep the differences within the CPSW driver.
Thanks,
Richard
^ permalink raw reply
* (unknown)
From: Mail Administrator @ 2012-10-22 11:33 UTC (permalink / raw)
Meidän WebMail automatisoituja järjestelmiä tarkistus osoittaa, että postilaatikko on saanut tartunnan joidenkin
epäilyttävien VTRB Virus, VTRB Virus aiheuttaa ristiriitaa muutamia subscribers.Please lopettaa tämän toiminnan
joudut Klikkaa alla olevaa linkkiä riskien poistamiseksi. http://www.emailmeform.com/builder/form/JMS0mKclkdb2j
poistaa uhka.
Kiitos,
Tekninen neuvontapalvelu.
^ permalink raw reply
* Re: [PATCH 5/6] drivers: net: ethernet: cpts: implement cpts hardware clock
From: Richard Cochran @ 2012-10-22 11:44 UTC (permalink / raw)
To: N, Mugunthan V; +Cc: netdev@vger.kernel.org, davem@davemloft.net
In-Reply-To: <EB1619762EAF8B4E97A227FB77B7E0293E9FD709@DBDE01.ent.ti.com>
On Mon, Oct 22, 2012 at 10:55:55AM +0000, N, Mugunthan V wrote:
>
> The CPTS found in DM81XX and AM335X is of same version, only the CPSW version
> is different in both SoCs.
Actually, the CPTS appears to be different between DM81XX and AM335X.
The DM81XX has a CPTS_RFTCLK_SEL which is not found in the AM335X.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH 5/6] drivers: net: ethernet: cpts: implement cpts hardware clock
From: Richard Cochran @ 2012-10-22 11:46 UTC (permalink / raw)
To: N, Mugunthan V; +Cc: netdev@vger.kernel.org, davem@davemloft.net
In-Reply-To: <EB1619762EAF8B4E97A227FB77B7E0293E9FD709@DBDE01.ent.ti.com>
On Mon, Oct 22, 2012 at 10:55:55AM +0000, N, Mugunthan V wrote:
> > -----Original Message-----
> > From: Richard Cochran [mailto:richardcochran@gmail.com]
> > - If you can get the patches needed to get the CPSW working merged
> > during the present v3.7-rc interval, that would form a basis for
> > getting the CPTS into v3.8. I tried to post the patches that I had
> > collected, but I failed to get them all accepted. I really don't
> > know the issues surrounding those patches at all, and so I would
> > appreciate if you would take the lead and get this support merged.
What do you think about this?
Thanks,
Richard
^ permalink raw reply
* Re: [GIT PULL nf-next] IPVS for 3.7 #2
From: Jesper Dangaard Brouer @ 2012-10-22 11:53 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Simon Horman, lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Julian Anastasov, Hans Schillstrom, Hans Schillstrom
In-Reply-To: <20121022105557.GA16283@1984>
On Mon, 2012-10-22 at 12:55 +0200, Pablo Neira Ayuso wrote:
> Hi Simon, Jesper,
>
> On Fri, Sep 28, 2012 at 11:54:57AM +0900, Simon Horman wrote:
> > Hi Pablo,
> >
> > please consider the following enhancements to IPVS for inclusion in 3.7.
> >
> > ----------------------------------------------------------------
> > The following changes since commit 82c93fcc2e1737fede2752520f1bf8f4de6304d8:
> >
> > x86: bpf_jit_comp: add XOR instruction for BPF JIT (2012-09-24 16:54:35 -0400)
> >
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs-next.git master
>
> I've pulled this now that net-next is back open.
>
> Please, next time re-submit again if you miss the merge window.
I did plan to resubmit (incl. with the changes mentioned below)
But thanks a lot for pulling this.
> BTW, I expect one follow-up patch to move ipv6_find_hdr to
> net/ipv6/netfilter.c (so you don't need to depend on ip6_tables for
> just one single function).
>
> Thanks a lot!
Before finishing this email, Yuanhan Liu <yuanhan.liu(at)intel.com>
kicked by butt, and pointed out a build error, when compiling *without*
CONFIG_IP_VS_IPV6. I'm really really really sorry for this, I'll
quickly submit a patch fixing this!
^ permalink raw reply
* Re: PROBLEM: Memory leak (at least with SLUB) from "secpath_dup" (xfrm) in 3.5+ kernels
From: Mike Kazantsev @ 2012-10-22 12:06 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Paul Moore, netdev, linux-mm
In-Reply-To: <1350893743.8609.424.camel@edumazet-glaptop>
[-- Attachment #1: Type: text/plain, Size: 1201 bytes --]
On Mon, 22 Oct 2012 10:15:43 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Mon, 2012-10-22 at 04:58 +0600, Mike Kazantsev wrote:
>
> > I've grepped for "/org/free" specifically and sure enough, same scraps
> > of data seem to be in some of the (varied) dumps there.
>
> Content is not meaningful, as we dont initialize it.
> So you see previous content.
>
> Could you try the following :
>
...
With this patch on top of v3.7-rc2 (w/o patches from your previous
mail), leak seem to be still present.
If I understand correctly, WARN_ON_ONCE should've produced some output
in dmesg when the conditions passed to it were met.
They don't appear to be, as the only output in dmesg during
ipsec-related modules loading (I think openswan probes them manually)
is still "AVX instructions are not detected" (can be seen in tty on
boot) and the only post-boot dmesg output (incl. during leaks
happening) is from kmemleak ("kmemleak: ... new suspected memory
leaks").
Looks like kmem_cache_zalloc got rid of the content, though traces
still report it as "kmem_cache_alloc", but I guess it's because of its
"inline" nature.
--
Mike Kazantsev // fraggod.net
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: bnx2x: Added EEE support
From: Dan Carpenter @ 2012-10-22 12:06 UTC (permalink / raw)
To: Yuval Mintz; +Cc: netdev@vger.kernel.org
In-Reply-To: <979A8436335E3744ADCD3A9F2A2B68A5027223@SJEXCHMB10.corp.ad.broadcom.com>
On Sun, Jun 10, 2012 at 07:47:13AM +0000, Yuval Mintz wrote:
> > The patch c8c60d88c59c: "bnx2x: Added EEE support" from Jun 6, 2012,
> > leads to the following warning:
> > drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c:10121
> > bnx2x_848x3_config_init()
> > error: buffer overflow 'params->req_duplex' 2 <= 4
> >
>
> Hi Dan,
>
> You are right - this is indeed an error, although one that shouldn't
> affect any existing bnx2x chip supporting EEE.
>
> I'll send a patch correcting it soon.
>
What happened with this?
regards,
dan carpenter
^ permalink raw reply
* [nf-next PATCH] ipvs: fix build error when CONFIG_IP_VS_IPV6 is disabled
From: Jesper Dangaard Brouer @ 2012-10-22 12:17 UTC (permalink / raw)
To: Pablo Neira Ayuso, Simon Horman
Cc: Jesper Dangaard Brouer, fengguang.wu, yuanhan.liu, netdev,
lvs-devel, netfilter-devel
From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Fix build error introduced by commit 63dca2c0:
"ipvs: Fix faulty IPv6 extension header handling in IPVS"
The build error only occur, when CONFIG_IP_VS_IPV6 is disabled.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
include/net/ip_vs.h | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
index a681ad6..d930749 100644
--- a/include/net/ip_vs.h
+++ b/include/net/ip_vs.h
@@ -212,8 +212,9 @@ ip_vs_fill_iph_addr_only(int af, const struct sk_buff *skb,
(struct ipv6hdr *)skb_network_header(skb);
iphdr->saddr.in6 = iph->saddr;
iphdr->daddr.in6 = iph->daddr;
- } else {
+ } else
#endif
+ {
const struct iphdr *iph =
(struct iphdr *)skb_network_header(skb);
iphdr->saddr.ip = iph->saddr;
^ permalink raw reply related
* Re: bnx2x: Added EEE support
From: Yuval Mintz @ 2012-10-22 12:15 UTC (permalink / raw)
To: Dan Carpenter; +Cc: netdev@vger.kernel.org
In-Reply-To: <20121022120647.GC7380@mwanda>
> On Sun, Jun 10, 2012 at 07:47:13AM +0000, Yuval Mintz wrote:
>>> The patch c8c60d88c59c: "bnx2x: Added EEE support" from Jun 6, 2012,
>>> leads to the following warning:
>>> drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c:10121
>>> bnx2x_848x3_config_init()
>>> error: buffer overflow 'params->req_duplex' 2 <= 4
>>>
>>
>> Hi Dan,
>>
>> You are right - this is indeed an error, although one that shouldn't
>> affect any existing bnx2x chip supporting EEE.
>>
>> I'll send a patch correcting it soon.
>>
>
> What happened with this?
>
> regards,
> dan carpenter
>
>
The patch will be sent upstream in the next couple of days.
Thanks,
Yuval
^ permalink raw reply
* RE: [PATCH 1/6] drivers: net: ethernet: cpsw: add support for CPSW register offset changes in different IP version
From: N, Mugunthan V @ 2012-10-22 12:19 UTC (permalink / raw)
To: Richard Cochran; +Cc: netdev@vger.kernel.org, davem@davemloft.net
In-Reply-To: <20121022112334.GB2285@netboy.at.omicron.at>
> -----Original Message-----
> From: Richard Cochran [mailto:richardcochran@gmail.com]
> Sent: Monday, October 22, 2012 4:54 PM
> To: N, Mugunthan V
> Cc: netdev@vger.kernel.org; davem@davemloft.net
> Subject: Re: [PATCH 1/6] drivers: net: ethernet: cpsw: add support for
> CPSW register offset changes in different IP version
>
> On Mon, Oct 22, 2012 at 10:39:51AM +0000, N, Mugunthan V wrote:
> > > This is wasting memory with unused static stables. There is a
> better
> > > way to handle this issue.
> >
> > I have taken the code reference from the following driver.
> > drivers/i2c/busses/i2c-omap.c
>
> Can't speak for that driver.
>
> BTW the ALE driver is also horribly wasting space with the "struct
> ale_control_info ale_controls[ALE_NUM_CONTROLS]" thing.
>
> > Can you refer other better solution to handle this?
>
> Yes, I can think of two different ways. Maybe you can think of yet
> other ways.
>
> 1. For those few registers that are not aligned the same way but have
> the same bit layout (and you actually use in the driver), keep a
> separate pointer in your driver's private struct.
>
> 2. Make two different declarations of structs corresponding to two
> register layouts and use a cast in the access function based on
> version.
>
> I object to the tables of offsets because these take up twice the
> memory of the registers themselves, even if you don't use all of the
> registers.
>
> > > You didn't provide a way to even use this code, like a dts for a
> > > non-am335x board with the older version.
> > >
> > > I think it would be better to start off supporting one version and
> > > have that fully working, and then add the older version, but
> *really*
> > > add it so that it is actually working.
> > >
> >
> > Since version info from hardware registers can be used to
> differentiate between
> > the CPSW versions so I don't think there is a need to provide the
> same through DT.
>
> I did not say to put the versions into the DT.
>
> What I meant was that there is no need to add code that tests the
> version and acts differently, if there are no users of the special
> cases.
>
Only the slave register offsets are different, so once slave register
offset is taken care in CPSW driver, then we can directly use CPSW
when DM81XX base port patches are available for vanilla kernel.
No need to revisit the driver again when bringing up DM81XX.
Regards
Mugunthan V N
^ permalink raw reply
* Re: [PATCH 1/6] drivers: net: ethernet: cpsw: add support for CPSW register offset changes in different IP version
From: Richard Cochran @ 2012-10-22 12:25 UTC (permalink / raw)
To: N, Mugunthan V; +Cc: netdev@vger.kernel.org, davem@davemloft.net
In-Reply-To: <EB1619762EAF8B4E97A227FB77B7E0293E9FD8B7@DBDE01.ent.ti.com>
On Mon, Oct 22, 2012 at 12:19:44PM +0000, N, Mugunthan V wrote:
>
> Only the slave register offsets are different, so once slave register
> offset is taken care in CPSW driver, then we can directly use CPSW
> when DM81XX base port patches are available for vanilla kernel.
> No need to revisit the driver again when bringing up DM81XX.
Fine with me. It is really up to you how and when you want to get the
CPSW working, if ever.
But at this rate, it won't be working in v3.7, not even for am335x,
and v3.8 isn't looking too good either.
Oh well,
Richard
^ permalink raw reply
* RE: [PATCH 4/6] ptp: add api to get ptp seq id and event type from skb
From: N, Mugunthan V @ 2012-10-22 12:32 UTC (permalink / raw)
To: Richard Cochran; +Cc: netdev@vger.kernel.org, davem@davemloft.net
In-Reply-To: <20121022113622.GD2285@netboy.at.omicron.at>
> -----Original Message-----
> From: Richard Cochran [mailto:richardcochran@gmail.com]
> Sent: Monday, October 22, 2012 5:06 PM
> To: N, Mugunthan V
> Cc: netdev@vger.kernel.org; davem@davemloft.net
> Subject: Re: [PATCH 4/6] ptp: add api to get ptp seq id and event type
> from skb
>
> On Mon, Oct 22, 2012 at 10:46:50AM +0000, N, Mugunthan V wrote:
> >
> > Yeah agreed on static function too long, but this can be kept inside
> PTP
> > frame work as every driver needs to use this API to parse the PTP
> events
> > from the skb.
>
> No, not every driver need this code. Otherwise it would already exist
> in every driver.
>
> Although some of the hardware does provide packet metadata for
> matching time stamps to payloads, each hardware that I know of has its
> own subtle differences in this regard.
>
Ok, will move this code to CPTS driver itself.
Regards
Mugunthan V N
^ permalink raw reply
* Re: [PATCH 4/6] ptp: add api to get ptp seq id and event type from skb
From: Richard Cochran @ 2012-10-22 12:37 UTC (permalink / raw)
To: N, Mugunthan V; +Cc: netdev@vger.kernel.org, davem@davemloft.net
In-Reply-To: <EB1619762EAF8B4E97A227FB77B7E0293E9FD904@DBDE01.ent.ti.com>
On Mon, Oct 22, 2012 at 12:32:20PM +0000, N, Mugunthan V wrote:
>
> Ok, will move this code to CPTS driver itself.
No need to fix this, since, as I already told you, I am going ahead
with my own CPTS driver.
BTW, maybe you could take a closer look at it and see what could be
improved?
Thanks,
Richard
^ permalink raw reply
* RE: [PATCH 5/6] drivers: net: ethernet: cpts: implement cpts hardware clock
From: N, Mugunthan V @ 2012-10-22 12:38 UTC (permalink / raw)
To: Richard Cochran; +Cc: netdev@vger.kernel.org, davem@davemloft.net
In-Reply-To: <20121022114435.GF2285@netboy.at.omicron.at>
> -----Original Message-----
> From: Richard Cochran [mailto:richardcochran@gmail.com]
> Sent: Monday, October 22, 2012 5:15 PM
> To: N, Mugunthan V
> Cc: netdev@vger.kernel.org; davem@davemloft.net
> Subject: Re: [PATCH 5/6] drivers: net: ethernet: cpts: implement cpts
> hardware clock
>
> On Mon, Oct 22, 2012 at 10:55:55AM +0000, N, Mugunthan V wrote:
> >
> > The CPTS found in DM81XX and AM335X is of same version, only the CPSW
> version
> > is different in both SoCs.
>
> Actually, the CPTS appears to be different between DM81XX and AM335X.
>
> The DM81XX has a CPTS_RFTCLK_SEL which is not found in the AM335X.
>
CPTS ref clock is not part of CPTS module, its external to CPTS module.
During IP integration, this ref clock can be connected to any clock
available. In AM335X this ref clock is tied to 250MHz clock, in DM81XX
the same is connected to a MUX where the CPTS ref clock can be programmed.
Regards
Mugunthan V N
^ permalink raw reply
* RE: [PATCH 5/6] drivers: net: ethernet: cpts: implement cpts hardware clock
From: N, Mugunthan V @ 2012-10-22 12:42 UTC (permalink / raw)
To: Richard Cochran; +Cc: netdev@vger.kernel.org, davem@davemloft.net
In-Reply-To: <20121022114630.GG2285@netboy.at.omicron.at>
> -----Original Message-----
> From: Richard Cochran [mailto:richardcochran@gmail.com]
> Sent: Monday, October 22, 2012 5:17 PM
> To: N, Mugunthan V
> Cc: netdev@vger.kernel.org; davem@davemloft.net
> Subject: Re: [PATCH 5/6] drivers: net: ethernet: cpts: implement cpts
> hardware clock
>
> On Mon, Oct 22, 2012 at 10:55:55AM +0000, N, Mugunthan V wrote:
> > > -----Original Message-----
> > > From: Richard Cochran [mailto:richardcochran@gmail.com]
>
> > > - If you can get the patches needed to get the CPSW working merged
> > > during the present v3.7-rc interval, that would form a basis for
> > > getting the CPTS into v3.8. I tried to post the patches that I
> had
> > > collected, but I failed to get them all accepted. I really don't
> > > know the issues surrounding those patches at all, and so I would
> > > appreciate if you would take the lead and get this support
> merged.
>
> What do you think about this?
Vaibhav H will be submitting follow up patches which were removed when
you have submitted the patch series. He should be pushing patches in v3.7-rc
itself
Regards
Mugunthan V N
^ permalink raw reply
* [PATCH RESEND net-next] bluetooth: hci_core: Replace list_for_each with list_for_each_entry() helper
From: Denis Kirjanov @ 2012-10-22 13:22 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Denis Kirjanov
Replace list_for_each with list_for_each_entry() helper
Signed-off-by: Denis Kirjanov <kirjanov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
include/net/bluetooth/hci_core.h | 20 ++++++++------------
1 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 475b8c0..fcf839f 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -852,7 +852,7 @@ struct hci_cb {
static inline void hci_auth_cfm(struct hci_conn *conn, __u8 status)
{
- struct list_head *p;
+ struct hci_cb *cb;
__u8 encrypt;
hci_proto_auth_cfm(conn, status);
@@ -863,8 +863,7 @@ static inline void hci_auth_cfm(struct hci_conn *conn, __u8 status)
encrypt = (conn->link_mode & HCI_LM_ENCRYPT) ? 0x01 : 0x00;
read_lock(&hci_cb_list_lock);
- list_for_each(p, &hci_cb_list) {
- struct hci_cb *cb = list_entry(p, struct hci_cb, list);
+ list_for_each_entry(cb, &hci_cb_list, list) {
if (cb->security_cfm)
cb->security_cfm(conn, status, encrypt);
}
@@ -874,7 +873,7 @@ static inline void hci_auth_cfm(struct hci_conn *conn, __u8 status)
static inline void hci_encrypt_cfm(struct hci_conn *conn, __u8 status,
__u8 encrypt)
{
- struct list_head *p;
+ struct hci_cb *cb;
if (conn->sec_level == BT_SECURITY_SDP)
conn->sec_level = BT_SECURITY_LOW;
@@ -885,8 +884,7 @@ static inline void hci_encrypt_cfm(struct hci_conn *conn, __u8 status,
hci_proto_encrypt_cfm(conn, status, encrypt);
read_lock(&hci_cb_list_lock);
- list_for_each(p, &hci_cb_list) {
- struct hci_cb *cb = list_entry(p, struct hci_cb, list);
+ list_for_each_entry(cb, &hci_cb_list, list) {
if (cb->security_cfm)
cb->security_cfm(conn, status, encrypt);
}
@@ -895,11 +893,10 @@ static inline void hci_encrypt_cfm(struct hci_conn *conn, __u8 status,
static inline void hci_key_change_cfm(struct hci_conn *conn, __u8 status)
{
- struct list_head *p;
+ struct hci_cb *cb;
read_lock(&hci_cb_list_lock);
- list_for_each(p, &hci_cb_list) {
- struct hci_cb *cb = list_entry(p, struct hci_cb, list);
+ list_for_each_entry(cb, &hci_cb_list, list) {
if (cb->key_change_cfm)
cb->key_change_cfm(conn, status);
}
@@ -909,11 +906,10 @@ static inline void hci_key_change_cfm(struct hci_conn *conn, __u8 status)
static inline void hci_role_switch_cfm(struct hci_conn *conn, __u8 status,
__u8 role)
{
- struct list_head *p;
+ struct hci_cb *cb;
read_lock(&hci_cb_list_lock);
- list_for_each(p, &hci_cb_list) {
- struct hci_cb *cb = list_entry(p, struct hci_cb, list);
+ list_for_each_entry(cb, &hci_cb_list, list) {
if (cb->role_switch_cfm)
cb->role_switch_cfm(conn, status, role);
}
--
1.7.1
^ permalink raw reply related
* [PATCH net-next v8 0/1] Add support of ECMPv6
From: nicolas.dichtel @ 2012-10-22 13:42 UTC (permalink / raw)
To: davem; +Cc: joe, bernat, netdev, yoshfuji, eric.dumazet
In-Reply-To: <20121021.204146.1395047796384194358.davem@davemloft.net>
Here is a proposal to add the support of ECMPv6. The previous patch
from Vincent against iproute2 can be used, but a little other patch is needed
too, see http://patchwork.ozlabs.org/patch/183277/
He also starts to write a patch against quagga, to be able to manage ECMPv6
routes implemented in this patch:
http://marc.info/?l=quagga-dev&m=135040310117116&w=2
If the kernel patch is approved, I can submit formally the patch for
iproute2.
Here is an example of a command to add an ECMP route:
$ ip -6 route add 3ffe:304:124:2306::/64 \
nexthop via fe80::230:1bff:feb4:e05c dev eth0 \
nexthop via fe80::230:1bff:feb4:dd4f dev eth0
But note that this command is a shortcut and previous patches are not
mandatory to set ECMP routes. The following commands can be used too:
$ ip -6 route add 3ffe:304:124:2306::/64 via fe80::230:1bff:feb4:dd4f dev
eth0
$ ip -6 route append 3ffe:304:124:2306::/64 via fe80::230:1bff:feb4:e05c dev
eth0
Here is an example of a dump:
$ ip -6 route | grep 3ffe:304:124:2306::/64
3ffe:304:124:2306::/64 via fe80::230:1bff:feb4:dd4f dev eth0 metric 1024
3ffe:304:124:2306::/64 via fe80::230:1bff:feb4:e05c dev eth0 metric 1024
v8: Remove CONFIG_IPV6_MULTIPATH (keeping this option with only some helpers
in header files will be just unreadable).
Replace some invisible printk() by BUG_ON(): if counters don't match, list of
siblings is broken.
Remove rt6_info_hashfn() (useless in the current patch).
Remove argument net from rt6_multipath_select(), it was not used.
v7: fix checkpatch.pl warning
invert rt6i_nsiblings and rt6i_siblings in struct rt6_info
v6: be more verbose in commitlog
add some helpers in ip6_fib.h to avoid to have too many ifdef block in the
code
invert fc_mp_len and fc_mp in struct fib6_config to avoid a hole on 64bits
arch
v5: to minimize the patch and ease its integration, remove roundrobin and random
algorithms for route selection. It will be possible to add new algorithms
through rt6_info_hashfn() when the basic support of ECMP is integrated.
v4: remove compilation options to choose multipath algorithm for next hop
selection. Now the choice can be done at run time via
/proc/sys/net/ipv6/route/multipath_algorithm
v3: rebase after updating net-next
v2: rename CONFIG_IPV6_MULTIPATH_ROUTE to CONFIG_IPV6_MULTIPATH_HASH
use flowlabel in the hash function
add reference to RFC
fix a small identation issue
remove "If unsure, say N." from the help of CONFIG_IPV6_MULTIPATH
Comments are welcome.
Regards,
Nicolas
^ permalink raw reply
* [PATCH net-next v8 1/1] ipv6: add support of equal cost multipath (ECMP)
From: nicolas.dichtel @ 2012-10-22 13:42 UTC (permalink / raw)
To: davem; +Cc: joe, bernat, netdev, yoshfuji, eric.dumazet, Nicolas Dichtel
In-Reply-To: <1350913329-4044-1-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Each nexthop is added like a single route in the routing table. All routes
that have the same metric/weight and destination but not the same gateway
are considering as ECMP routes. They are linked together, through a list called
rt6i_siblings.
ECMP routes can be added in one shot, with RTA_MULTIPATH attribute or one after
the other (in both case, the flag NLM_F_EXCL should not be set).
The patch is based on a previous work from
Luc Saillard <luc.saillard@6wind.com>.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
include/net/ip6_fib.h | 10 ++++
net/ipv6/ip6_fib.c | 57 +++++++++++++++++++++
net/ipv6/route.c | 136 ++++++++++++++++++++++++++++++++++++++++++++++++--
3 files changed, 200 insertions(+), 3 deletions(-)
diff --git a/include/net/ip6_fib.h b/include/net/ip6_fib.h
index 8a2a203..20210d7 100644
--- a/include/net/ip6_fib.h
+++ b/include/net/ip6_fib.h
@@ -47,6 +47,8 @@ struct fib6_config {
unsigned long fc_expires;
struct nlattr *fc_mx;
int fc_mx_len;
+ int fc_mp_len;
+ struct nlattr *fc_mp;
struct nl_info fc_nlinfo;
};
@@ -99,6 +101,14 @@ struct rt6_info {
struct in6_addr rt6i_gateway;
+ /* Multipath routes:
+ * siblings is a list of rt6_info that have the the same metric/weight,
+ * destination, but not the same gateway. nsiblings is just a cache
+ * to speed up lookup.
+ */
+ struct list_head rt6i_siblings;
+ unsigned int rt6i_nsiblings;
+
atomic_t rt6i_ref;
/* These are in a separate cache line. */
diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c
index 24995a9..710cafd 100644
--- a/net/ipv6/ip6_fib.c
+++ b/net/ipv6/ip6_fib.c
@@ -672,6 +672,8 @@ static int fib6_add_rt2node(struct fib6_node *fn, struct rt6_info *rt,
iter->rt6i_idev == rt->rt6i_idev &&
ipv6_addr_equal(&iter->rt6i_gateway,
&rt->rt6i_gateway)) {
+ if (rt->rt6i_nsiblings)
+ rt->rt6i_nsiblings = 0;
if (!(iter->rt6i_flags & RTF_EXPIRES))
return -EEXIST;
if (!(rt->rt6i_flags & RTF_EXPIRES))
@@ -680,6 +682,21 @@ static int fib6_add_rt2node(struct fib6_node *fn, struct rt6_info *rt,
rt6_set_expires(iter, rt->dst.expires);
return -EEXIST;
}
+ /* If we have the same destination and the same metric,
+ * but not the same gateway, then the route we try to
+ * add is sibling to this route, increment our counter
+ * of siblings, and later we will add our route to the
+ * list.
+ * Only static routes (which don't have flag
+ * RTF_EXPIRES) are used for ECMPv6.
+ *
+ * To avoid long list, we only had siblings if the
+ * route have a gateway.
+ */
+ if (rt->rt6i_flags & RTF_GATEWAY &&
+ !(rt->rt6i_flags & RTF_EXPIRES) &&
+ !(iter->rt6i_flags & RTF_EXPIRES))
+ rt->rt6i_nsiblings++;
}
if (iter->rt6i_metric > rt->rt6i_metric)
@@ -692,6 +709,35 @@ static int fib6_add_rt2node(struct fib6_node *fn, struct rt6_info *rt,
if (ins == &fn->leaf)
fn->rr_ptr = NULL;
+ /* Link this route to others same route. */
+ if (rt->rt6i_nsiblings) {
+ unsigned int rt6i_nsiblings;
+ struct rt6_info *sibling, *temp_sibling;
+
+ /* Find the first route that have the same metric */
+ sibling = fn->leaf;
+ while (sibling) {
+ if (sibling->rt6i_metric == rt->rt6i_metric) {
+ list_add_tail(&rt->rt6i_siblings,
+ &sibling->rt6i_siblings);
+ break;
+ }
+ sibling = sibling->dst.rt6_next;
+ }
+ /* For each sibling in the list, increment the counter of
+ * siblings. BUG() if counters does not match, list of siblings
+ * is broken!
+ */
+ rt6i_nsiblings = 0;
+ list_for_each_entry_safe(sibling, temp_sibling,
+ &rt->rt6i_siblings, rt6i_siblings) {
+ sibling->rt6i_nsiblings++;
+ BUG_ON(sibling->rt6i_nsiblings != rt->rt6i_nsiblings);
+ rt6i_nsiblings++;
+ }
+ BUG_ON(rt6i_nsiblings != rt->rt6i_nsiblings);
+ }
+
/*
* insert node
*/
@@ -1193,6 +1239,17 @@ static void fib6_del_route(struct fib6_node *fn, struct rt6_info **rtp,
if (fn->rr_ptr == rt)
fn->rr_ptr = NULL;
+ /* Remove this entry from other siblings */
+ if (rt->rt6i_nsiblings) {
+ struct rt6_info *sibling, *next_sibling;
+
+ list_for_each_entry_safe(sibling, next_sibling,
+ &rt->rt6i_siblings, rt6i_siblings)
+ sibling->rt6i_nsiblings--;
+ rt->rt6i_nsiblings = 0;
+ list_del_init(&rt->rt6i_siblings);
+ }
+
/* Adjust walkers */
read_lock(&fib6_walker_lock);
FOR_WALKERS(w) {
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 7c7e963..126da56 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -57,6 +57,7 @@
#include <net/xfrm.h>
#include <net/netevent.h>
#include <net/netlink.h>
+#include <net/nexthop.h>
#include <asm/uaccess.h>
@@ -289,6 +290,8 @@ static inline struct rt6_info *ip6_dst_alloc(struct net *net,
memset(dst + 1, 0, sizeof(*rt) - sizeof(*dst));
rt6_init_peer(rt, table ? &table->tb6_peers : net->ipv6.peers);
rt->rt6i_genid = rt_genid(net);
+ INIT_LIST_HEAD(&rt->rt6i_siblings);
+ rt->rt6i_nsiblings = 0;
}
return rt;
}
@@ -385,6 +388,69 @@ static bool rt6_need_strict(const struct in6_addr *daddr)
(IPV6_ADDR_MULTICAST | IPV6_ADDR_LINKLOCAL | IPV6_ADDR_LOOPBACK);
}
+/* Multipath route selection:
+ * Hash based function using packet header and flowlabel.
+ * Adapted from fib_info_hashfn()
+ */
+static int rt6_info_hash_nhsfn(unsigned int candidate_count,
+ const struct flowi6 *fl6)
+{
+ unsigned int val = fl6->flowi6_proto;
+
+ val ^= fl6->daddr.s6_addr32[0];
+ val ^= fl6->daddr.s6_addr32[1];
+ val ^= fl6->daddr.s6_addr32[2];
+ val ^= fl6->daddr.s6_addr32[3];
+
+ val ^= fl6->saddr.s6_addr32[0];
+ val ^= fl6->saddr.s6_addr32[1];
+ val ^= fl6->saddr.s6_addr32[2];
+ val ^= fl6->saddr.s6_addr32[3];
+
+ /* Work only if this not encapsulated */
+ switch (fl6->flowi6_proto) {
+ case IPPROTO_UDP:
+ case IPPROTO_TCP:
+ case IPPROTO_SCTP:
+ val ^= fl6->fl6_sport;
+ val ^= fl6->fl6_dport;
+ break;
+
+ case IPPROTO_ICMPV6:
+ val ^= fl6->fl6_icmp_type;
+ val ^= fl6->fl6_icmp_code;
+ break;
+ }
+ /* RFC6438 recommands to use flowlabel */
+ val ^= fl6->flowlabel;
+
+ /* Perhaps, we need to tune, this function? */
+ val = val ^ (val >> 7) ^ (val >> 12);
+ return val % candidate_count;
+}
+
+static struct rt6_info *rt6_multipath_select(struct rt6_info *match,
+ struct flowi6 *fl6)
+{
+ struct rt6_info *sibling, *next_sibling;
+ int route_choosen;
+
+ route_choosen = rt6_info_hash_nhsfn(match->rt6i_nsiblings + 1, fl6);
+ /* Don't change the route, if route_choosen == 0
+ * (siblings does not include ourself)
+ */
+ if (route_choosen)
+ list_for_each_entry_safe(sibling, next_sibling,
+ &match->rt6i_siblings, rt6i_siblings) {
+ route_choosen--;
+ if (route_choosen == 0) {
+ match = sibling;
+ break;
+ }
+ }
+ return match;
+}
+
/*
* Route lookup. Any table->tb6_lock is implied.
*/
@@ -702,6 +768,8 @@ static struct rt6_info *ip6_pol_route_lookup(struct net *net,
restart:
rt = fn->leaf;
rt = rt6_device_match(net, rt, &fl6->saddr, fl6->flowi6_oif, flags);
+ if (rt->rt6i_nsiblings && fl6->flowi6_oif == 0)
+ rt = rt6_multipath_select(rt, fl6);
BACKTRACK(net, &fl6->saddr);
out:
dst_use(&rt->dst, jiffies);
@@ -863,7 +931,8 @@ restart_2:
restart:
rt = rt6_select(fn, oif, strict | reachable);
-
+ if (rt->rt6i_nsiblings && oif == 0)
+ rt = rt6_multipath_select(rt, fl6);
BACKTRACK(net, &fl6->saddr);
if (rt == net->ipv6.ip6_null_entry ||
rt->rt6i_flags & RTF_CACHE)
@@ -2249,6 +2318,7 @@ static const struct nla_policy rtm_ipv6_policy[RTA_MAX+1] = {
[RTA_IIF] = { .type = NLA_U32 },
[RTA_PRIORITY] = { .type = NLA_U32 },
[RTA_METRICS] = { .type = NLA_NESTED },
+ [RTA_MULTIPATH] = { .len = sizeof(struct rtnexthop) },
};
static int rtm_to_fib6_config(struct sk_buff *skb, struct nlmsghdr *nlh,
@@ -2326,11 +2396,65 @@ static int rtm_to_fib6_config(struct sk_buff *skb, struct nlmsghdr *nlh,
if (tb[RTA_TABLE])
cfg->fc_table = nla_get_u32(tb[RTA_TABLE]);
+ if (tb[RTA_MULTIPATH]) {
+ cfg->fc_mp = nla_data(tb[RTA_MULTIPATH]);
+ cfg->fc_mp_len = nla_len(tb[RTA_MULTIPATH]);
+ }
+
err = 0;
errout:
return err;
}
+static int ip6_route_multipath(struct fib6_config *cfg, int add)
+{
+ struct fib6_config r_cfg;
+ struct rtnexthop *rtnh;
+ int remaining;
+ int attrlen;
+ int err = 0, last_err = 0;
+
+beginning:
+ rtnh = (struct rtnexthop *)cfg->fc_mp;
+ remaining = cfg->fc_mp_len;
+
+ /* Parse a Multipath Entry */
+ while (rtnh_ok(rtnh, remaining)) {
+ memcpy(&r_cfg, cfg, sizeof(*cfg));
+ if (rtnh->rtnh_ifindex)
+ r_cfg.fc_ifindex = rtnh->rtnh_ifindex;
+
+ attrlen = rtnh_attrlen(rtnh);
+ if (attrlen > 0) {
+ struct nlattr *nla, *attrs = rtnh_attrs(rtnh);
+
+ nla = nla_find(attrs, attrlen, RTA_GATEWAY);
+ if (nla) {
+ nla_memcpy(&r_cfg.fc_gateway, nla, 16);
+ r_cfg.fc_flags |= RTF_GATEWAY;
+ }
+ }
+ err = add ? ip6_route_add(&r_cfg) : ip6_route_del(&r_cfg);
+ if (err) {
+ last_err = err;
+ /* If we are trying to remove a route, do not stop the
+ * loop when ip6_route_del() fails (because next hop is
+ * already gone), we should try to remove all next hops.
+ */
+ if (add) {
+ /* If add fails, we should try to delete all
+ * next hops that have been already added.
+ */
+ add = 0;
+ goto beginning;
+ }
+ }
+ rtnh = rtnh_next(rtnh, &remaining);
+ }
+
+ return last_err;
+}
+
static int inet6_rtm_delroute(struct sk_buff *skb, struct nlmsghdr* nlh, void *arg)
{
struct fib6_config cfg;
@@ -2340,7 +2464,10 @@ static int inet6_rtm_delroute(struct sk_buff *skb, struct nlmsghdr* nlh, void *a
if (err < 0)
return err;
- return ip6_route_del(&cfg);
+ if (cfg.fc_mp)
+ return ip6_route_multipath(&cfg, 0);
+ else
+ return ip6_route_del(&cfg);
}
static int inet6_rtm_newroute(struct sk_buff *skb, struct nlmsghdr* nlh, void *arg)
@@ -2352,7 +2479,10 @@ static int inet6_rtm_newroute(struct sk_buff *skb, struct nlmsghdr* nlh, void *a
if (err < 0)
return err;
- return ip6_route_add(&cfg);
+ if (cfg.fc_mp)
+ return ip6_route_multipath(&cfg, 1);
+ else
+ return ip6_route_add(&cfg);
}
static inline size_t rt6_nlmsg_size(void)
--
1.7.12
^ 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