* [PATCH 1/2] jme: replace calls to redundant function
From: Quentin Lambert @ 2014-12-12 12:35 UTC (permalink / raw)
To: Guo-Fu Tseng; +Cc: netdev, linux-kernel
Calls to tasklet_hi_enable are replaced by calls to
tasklet_enable since the 2 functions are redundant.
Signed-off-by: Quentin Lambert <lambert.quentin@gmail.com>
Signed-off-by: Valentin Rothberg <valentinrothberg@gmail.com>
---
drivers/net/ethernet/jme.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/jme.c b/drivers/net/ethernet/jme.c
index 4a1be34..44ce7d8 100644
--- a/drivers/net/ethernet/jme.c
+++ b/drivers/net/ethernet/jme.c
@@ -1364,8 +1364,8 @@ err_out_free_rx_resources:
jme_free_rx_resources(jme);
out_enable_tasklet:
tasklet_enable(&jme->txclean_task);
- tasklet_hi_enable(&jme->rxclean_task);
- tasklet_hi_enable(&jme->rxempty_task);
+ tasklet_enable(&jme->rxclean_task);
+ tasklet_enable(&jme->rxempty_task);
out:
atomic_inc(&jme->link_changing);
}
@@ -2408,8 +2408,8 @@ static inline void jme_resume_rx(struct jme_adapter *jme)
if (test_bit(JME_FLAG_POLL, &jme->flags)) {
JME_NAPI_ENABLE(jme);
} else {
- tasklet_hi_enable(&jme->rxclean_task);
- tasklet_hi_enable(&jme->rxempty_task);
+ tasklet_enable(&jme->rxclean_task);
+ tasklet_enable(&jme->rxempty_task);
}
dpi->cur = PCC_P1;
dpi->attempt = PCC_P1;
@@ -3290,8 +3290,8 @@ jme_suspend(struct device *dev)
}
tasklet_enable(&jme->txclean_task);
- tasklet_hi_enable(&jme->rxclean_task);
- tasklet_hi_enable(&jme->rxempty_task);
+ tasklet_enable(&jme->rxclean_task);
+ tasklet_enable(&jme->rxempty_task);
jme_powersave_phy(jme);
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] linux/interrupt.h: remove the definition of unused tasklet_hi_enable
From: Quentin Lambert @ 2014-12-12 12:36 UTC (permalink / raw)
To: Guo-Fu Tseng; +Cc: netdev, linux-kernel
Signed-off-by: Quentin Lambert <lambert.quentin@gmail.com>
Signed-off-by: Valentin Rothberg <valentinrothberg@gmail.com>
---
include/linux/interrupt.h | 6 ------
1 file changed, 6 deletions(-)
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 69517a2..d9b05b5 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -556,12 +556,6 @@ static inline void tasklet_enable(struct tasklet_struct *t)
atomic_dec(&t->count);
}
-static inline void tasklet_hi_enable(struct tasklet_struct *t)
-{
- smp_mb__before_atomic();
- atomic_dec(&t->count);
-}
-
extern void tasklet_kill(struct tasklet_struct *t);
extern void tasklet_kill_immediate(struct tasklet_struct *t, unsigned int cpu);
extern void tasklet_init(struct tasklet_struct *t,
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net] net: ethernet: davicom: Allow to select DM9000 for nios2
From: Tobias Klauser @ 2014-12-12 12:40 UTC (permalink / raw)
To: Simon Horman; +Cc: netdev
In-Reply-To: <20141212112842.GA17780@verge.net.au>
On 2014-12-12 at 12:28:42 +0100, Simon Horman <horms@verge.net.au> wrote:
> On Fri, Dec 12, 2014 at 10:21:11AM +0100, Tobias Klauser wrote:
> > This chip is present on older revisions of the DE2 development kit.
> >
> > Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
>
> I wonder if || COMPILE_TEST should also be added to allow extra build
> coverage. Is there a specific reason it won't compile more widely?
>
> Likewise for your smsc patch.
Good point. I don't think there's a reason for it not being compiled
more widely. Should I update my patches accordingly or send a separate
patch?
^ permalink raw reply
* Re: [netdev01] registration inconsistency
From: Jamal Hadi Salim @ 2014-12-12 13:12 UTC (permalink / raw)
To: Johannes Berg
Cc: netdev01, Brenda Butler, netdev@vger.kernel.org,
Richard Guy Briggs
In-Reply-To: <1418387022.2470.26.camel@sipsolutions.net>
On 12/12/14 07:23, Johannes Berg wrote:
> On Fri, 2014-12-12 at 06:42 -0500, Jamal Hadi Salim wrote:
>
>> For workshops, you should go ahead and invite people you want.
>> If you want us to give codes to some people (means either they dont
>> have to pay or get discounts) then ping bjb and/or myself.
>
> No no, I don't think any (many) people will need a discount.
>
>> I am not sure how we distinguish invited people vs not-invited. It
>> would be nice to be able to do so.
>> One way is to do what the IETF does; provide color coded badges?
>> Also:
>> Do you think we need to change the language on the web site
>> to avoid any confusion?
>
> I think the confusion is that the CFP and the website say the conference
> is going to be be 50% speakers and 50% invitation: "The netdev
> conference this year is structured to be 50/50 by-invitation and talk
> submission"
>
> Looking back at this, I think you meant that the *talks* were going to
> be 50/50 like that, but some people have contacted me about that they
> thought *attendance* was going to be like that. In fact I just glossed
> over it and until now thought the same!
>
> If I'm right that you meant *talks* then I think you should clarify that
> language and even send out a clarification as a reply to the CFP email.
>
I think i got it.
Either a reply or we fix the CFP on the website.
Ccing Richard.
cheers,
jamal
^ permalink raw reply
* Re: [netdev01] registration inconsistency
From: Johannes Berg @ 2014-12-12 13:19 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: netdev01, Brenda Butler, netdev@vger.kernel.org,
Richard Guy Briggs
In-Reply-To: <548AE9AF.90902@mojatatu.com>
On Fri, 2014-12-12 at 08:12 -0500, Jamal Hadi Salim wrote:
> > Looking back at this, I think you meant that the *talks* were going to
> > be 50/50 like that, but some people have contacted me about that they
> > thought *attendance* was going to be like that. In fact I just glossed
> > over it and until now thought the same!
> >
> > If I'm right that you meant *talks* then I think you should clarify that
> > language and even send out a clarification as a reply to the CFP email.
> >
>
> I think i got it.
> Either a reply or we fix the CFP on the website.
> Ccing Richard.
I think a reply message would be good so it lands with those people who
might have gotten the original and misinterpreted it as well. Your
call :)
johannes
^ permalink raw reply
* Re: [PATCH net-next RESEND] net: Do not call ndo_dflt_fdb_dump if ndo_fdb_dump is defined.
From: Hubert Sokolowski @ 2014-12-12 13:36 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Hubert Sokolowski, Roopa Prabhu, netdev@vger.kernel.org,
Vlad Yasevich
In-Reply-To: <548AD781.5020004@mojatatu.com>
> On 12/12/14 06:38, Hubert Sokolowski wrote:
>>> On 12/11/14, 9:06 AM, Hubert Sokolowski wrote:
>
>> Please see how the ndo_dflt_fdb_add and del are called:
>> if (dev->netdev_ops->ndo_fdb_add)
>> err = dev->netdev_ops->ndo_fdb_add(ndm, tb, dev, addr,
>> vid,
>> nlh->nlmsg_flags);
>> else
>> err = ndo_dflt_fdb_add(ndm, tb, dev, addr, vid,
>> nlh->nlmsg_flags);
>>
>
> Semantically add and dump are not the same.
> Add adds a specific entry.
> Dump not only dumps the fdb table but also the unicast and multicast
> addresses.
this is not true for 3.16 and before. Please see:
http://lxr.free-electrons.com/source/net/core/rtnetlink.c?v=3.16#L2545
It lets you fully manage the FDB table by overwriding fdb_add, del and dump
in the same way.
>
>
>> As it was suggested by Ronen I can modify the patch so the dflt callback
>> is always called for bridge devices if this is desirable. Either by calling
>> it when following expression is true:
>> (dev->priv_flags & IFF_BRIDGE_PORT)
>> or by modifying br_fdb_dump to call ndo_dflt_fdb_dump.
>>
>
> Are you saying the above is going to work? You need to TEST please.
yes, it works and it is not a rocket science :). we just need to agree
on the approach to use.
>
> It seems to me drivers which do this:
> ---
> .ndo_fdb_dump = my_fdb_dump,
>
> and then my_fdb_dump is:
> return ndo_dflt_fdb_dump(skb, ncb, netdev, filter_dev, idx);
>
> are broken because we always have to dump the uni/multicast
> addresses *unconditionally* and these drivers claim to be
> overriding the dumper but are in fact calling the default dumper.
> They are not filtering anything as you had stated.
> I wish Vlad (Cced) would show up and say something ;->
>
> IOW, fix all the broken driver to not do that.
These "broken" drivers were written before 3.17 when the unconditional call
to dflt_dump was introduced. Some drivers implement own dump and don't
call dflt_dump at all, some call dflt_dump depending on some condition.
You can also call dflt_dump inside, save the idx result and continue
with own dump resulting in both uc/mc and own entries returned to the user.
thanks,
Hubert
^ permalink raw reply
* Re: [PATCH net] net: ethernet: davicom: Allow to select DM9000 for nios2
From: Simon Horman @ 2014-12-12 13:58 UTC (permalink / raw)
To: Tobias Klauser; +Cc: netdev
In-Reply-To: <20141212124015.GH16916@distanz.ch>
On Fri, Dec 12, 2014 at 01:40:15PM +0100, Tobias Klauser wrote:
> On 2014-12-12 at 12:28:42 +0100, Simon Horman <horms@verge.net.au> wrote:
> > On Fri, Dec 12, 2014 at 10:21:11AM +0100, Tobias Klauser wrote:
> > > This chip is present on older revisions of the DE2 development kit.
> > >
> > > Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
> >
> > I wonder if || COMPILE_TEST should also be added to allow extra build
> > coverage. Is there a specific reason it won't compile more widely?
> >
> > Likewise for your smsc patch.
>
> Good point. I don't think there's a reason for it not being compiled
> more widely. Should I update my patches accordingly or send a separate
> patch?
I'm not the maintainer but a follow-up patch or patches seems reasonable to me.
^ permalink raw reply
* Re: [netdev01] registration inconsistency
From: Richard Guy Briggs @ 2014-12-12 14:01 UTC (permalink / raw)
To: Johannes Berg
Cc: Jamal Hadi Salim, netdev01, Brenda Butler, netdev@vger.kernel.org,
Richard Guy Briggs
In-Reply-To: <1418390391.2470.45.camel@sipsolutions.net>
On 14/12/12, Johannes Berg wrote:
> On Fri, 2014-12-12 at 08:12 -0500, Jamal Hadi Salim wrote:
>
> > > Looking back at this, I think you meant that the *talks* were going to
> > > be 50/50 like that, but some people have contacted me about that they
> > > thought *attendance* was going to be like that. In fact I just glossed
> > > over it and until now thought the same!
> > >
> > > If I'm right that you meant *talks* then I think you should clarify that
> > > language and even send out a clarification as a reply to the CFP email.
> >
> > I think i got it.
> > Either a reply or we fix the CFP on the website.
> > Ccing Richard.
>
> I think a reply message would be good so it lands with those people who
> might have gotten the original and misinterpreted it as well. Your
> call :)
I totally missed that as well, but agree it should be clarified with a reply
and a news item on the web site as well as a change to the wording on the web
site.
> johannes
slainte mhath, RGB
--
Richard Guy Briggs -- ~\ -- ~\ <hpv.tricolour.ca>
<www.TriColour.ca> -- \___ o \@ @ Ride yer bike!
Ottawa, ON, CANADA -- Lo_>__M__\\/\%__\\/\%
Vote! -- <greenparty.ca>_____GTVS6#790__(*)__(*)________(*)(*)_________________
^ permalink raw reply
* Re: [PATCH v2 0/6] net-PPP: Deletion of a few unnecessary checks
From: David Miller @ 2014-12-12 14:29 UTC (permalink / raw)
To: elfring
Cc: sergei.shtylyov, paulus, linux-ppp, netdev, eric.dumazet,
linux-kernel, kernel-janitors, julia.lawall
In-Reply-To: <548A92E2.8090304@users.sourceforge.net>
From: SF Markus Elfring <elfring@users.sourceforge.net>
Date: Fri, 12 Dec 2014 08:01:54 +0100
>> Generally speaking, it is advisable to not leave error pointers in data
>> structures, even if they are about to be free'd up in an error path anyways.
>>
>> Therefore I do not like some of the patches in this series.
>
> Can you give any more concrete feedback here?
I gave you very concrete feedback, I said exactly that I don't want
error pointers left in data structure members.
I cannot describe my requirements any more precisely than that.
^ permalink raw reply
* Re: [PATCH net-next RESEND] net: Do not call ndo_dflt_fdb_dump if ndo_fdb_dump is defined.
From: Jamal Hadi Salim @ 2014-12-12 14:35 UTC (permalink / raw)
To: Hubert Sokolowski; +Cc: Roopa Prabhu, netdev@vger.kernel.org, Vlad Yasevich
In-Reply-To: <4c22a6c452a73b3b77a9a9c8e7f76bcc.squirrel@poczta.wsisiz.edu.pl>
On 12/12/14 08:36, Hubert Sokolowski wrote:
>> On 12/12/14 06:38, Hubert Sokolowski wrote:
>>>> On 12/11/14, 9:06 AM, Hubert Sokolowski wrote:
>>
>>> Please see how the ndo_dflt_fdb_add and del are called:
>>> if (dev->netdev_ops->ndo_fdb_add)
>>> err = dev->netdev_ops->ndo_fdb_add(ndm, tb, dev, addr,
>>> vid,
>>> nlh->nlmsg_flags);
>>> else
>>> err = ndo_dflt_fdb_add(ndm, tb, dev, addr, vid,
>>> nlh->nlmsg_flags);
>>>
>>
>> Semantically add and dump are not the same.
>> Add adds a specific entry.
>> Dump not only dumps the fdb table but also the unicast and multicast
>> addresses.
> this is not true for 3.16 and before. Please see:
> http://lxr.free-electrons.com/source/net/core/rtnetlink.c?v=3.16#L2545
> It lets you fully manage the FDB table by overwriding fdb_add, del and dump
> in the same way.
>
>
>
>>
>>
>>> As it was suggested by Ronen I can modify the patch so the dflt callback
>>> is always called for bridge devices if this is desirable. Either by calling
>>> it when following expression is true:
>>> (dev->priv_flags & IFF_BRIDGE_PORT)
>>> or by modifying br_fdb_dump to call ndo_dflt_fdb_dump.
>>>
>>
>> Are you saying the above is going to work? You need to TEST please.
> yes, it works and it is not a rocket science :). we just need to agree
> on the approach to use.
>
I am happy if this solves wont break
any of the use cases Vlad made me test and make sure work.
When i said "test" - I mean run the testcases outlined in the
commit log; if those work i dont see what the issue is.
cheers,
jamal
^ permalink raw reply
* Re: [netdev01] registration inconsistency
From: Jamal Hadi Salim @ 2014-12-12 14:45 UTC (permalink / raw)
To: Richard Guy Briggs, Johannes Berg
Cc: netdev01, Brenda Butler, netdev@vger.kernel.org,
Richard Guy Briggs
In-Reply-To: <20141212140108.GU392@toccata2.tricolour.ca>
On 12/12/14 09:01, Richard Guy Briggs wrote:
> I totally missed that as well, but agree it should be clarified with a reply
> and a news item on the web site as well as a change to the wording on the web
> site.
>
Sounds reasonable to me.
cheers,
jamal
^ permalink raw reply
* Re: tg3 broken in 3.18.0?
From: Jonathan Bither @ 2014-12-12 14:50 UTC (permalink / raw)
To: Marcelo Ricardo Leitner, Nils Holland, netdev
In-Reply-To: <5489CA3C.10803@gmail.com>
Not sure if it helps any, but tg3 works here after a 3.18 upgrade. I'd
be happy to share any information if it would help you out.
[root@www ~]# uname -a
Linux localhost 3.18.0-1.el6.elrepo.i686 #1 SMP Mon Dec 8 10:55:34 EST
2014 i686 i686 i386 GNU/Linux
[root@www ~]# ethtool -i eth0
driver: tg3
version: 3.137
firmware-version: 5704-v3.36, ASFIPMIc v2.37
bus-info: 0000:02:03.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no
[root@www ~]# ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: on
Supports Wake-on: g
Wake-on: g
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: yes
[root@www ~]#
On 12/11/2014 11:45 AM, Marcelo Ricardo Leitner wrote:
> On 10-12-2014 21:06, Nils Holland wrote:
>> Hi everyone,
>>
>> I just upgraded a machine from 3.17.3 to 3.18.0 and noticed that after
>> the upgrade, the machine's network interface (which is a tg3) would no
>> longer run correctly (or, for that matter, run at all). During the
>> upgrade, I didn't change any kernel config options or any other parts
>> of the system.
>
> Same thing here! Thanks for reporting this, Nils.
>
>> Since the machine is remote and I don't have direct access to it, it's
>> kind of hard currently to give more details, but here's what I'm
>> seeing in the logs:
>
> I have access to mine, kudos to secondary NIC.
>
> $ ethtool -i p1p1
> driver: tg3
> version: 3.137
> firmware-version: 5722-v3.13
> bus-info: 0000:02:00.0
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: yes
> supports-register-dump: yes
> supports-priv-flags: no
>
> $ ethtool p1p1
> Settings for p1p1:
> Supported ports: [ TP ]
> Supported link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Half 1000baseT/Full
> Supported pause frame use: No
> Supports auto-negotiation: Yes
> Advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Half 1000baseT/Full
> Advertised pause frame use: Symmetric
> Advertised auto-negotiation: Yes
> Speed: Unknown!
> Duplex: Unknown! (255)
> Port: Twisted Pair
> PHYAD: 1
> Transceiver: internal
> Auto-negotiation: on
> MDI-X: Unknown
>
> $ sudo ip link set p1p1 up
> RTNETLINK answers: No such device
>
>> If I see things correctly, there were only two patches affecting tg3
>> between 3.17(.3) and 3.18:
>>
>> 2c7c9ea429ba30fe506747b7da110e2212d8fefa
>> a620a6bc1c94c22d6c312892be1e0ae171523125
>
> I'm running net-next, 395eea6ccf2b253f81b4718ffbcae67d36fe2e69.
> So my diffs would be:
> $ git log v3.17..origin/master --oneline --
> drivers/net/ethernet/broadcom/tg3.c
> 892311f ethtool: Support for configurable RSS hash function
> 60b7379 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
> a620a6b tg3: fix ring init when there are more TX than RX channels
> 3964835 tg3: use netdev_rss_key_fill() helper
> 2c7c9ea tg3: Add skb->xmit_more support
>
> Reverting all these, issue continues.
>
> If no one has a better shot, I'll try bissecting later.
>
> Marcelo
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* NetDev 0.1 Attendee clarification [was: Netdev 0.1 Call for Proposals]
From: Richard Guy Briggs @ 2014-12-12 15:09 UTC (permalink / raw)
To: netdev, linux-wireless, lwn, netdev01, lartc, netfilter,
netfilter-devel
In-Reply-To: <20141203022815.GM4612@toccata2.tricolour.ca>
On 14/12/02, Richard Guy Briggs wrote:
> Netdev 0.1 Call for Proposals
> -----------------------------
>
> Netdev 0.1 (year 0, conference 1) is a community-driven conference
> geared towards Linux netheads. Linux kernel networking and user
> space utilization of the interfaces to the Linux kernel networking
> subsystem are the focus.
Hello fellow Linux NetHeads, sorry for the noise:
There seems to have been some questions about the intended audience for this
conference.
The 50/50 by-invitation/submission slots are for the *presenters* of the talks
and not for the audience of attendees. *Anyone* with an interest in Linux
networking is welcome to attend this conference.
We're very sorry for the confusion and welcome you to join us.
Cheers.
> There are 4 phases/formats to Netdev 0.1
>
> 1) Workshops (day 1)
>
> The workshop format is inspired by Netconf and the wireless
> mini-summits, with workshops being centered around existing
> networking subsystems. workshops are intended to be an extension of
> the mailing list in the sense that many times previous
> discussions from the mailing list (or that could otherwise have
> happened there) are taken to the round-table to simplify the
> decision-making process.
>
> The networking subsystem maintainer(s) should at least prepare a
> list of agenda items well before the workshop takes place to allow
> participants to come prepared; this makes the discussions most productive.
> Sometimes brain-storming sessions will also be appropriate where
> being prepared is less important, for example for discussions
> around new user requirements this can be very valuable.
>
> At the workshop meeting itself discussions prevail and notes are
> later sent back to the mailing list; presentations are typically
> - at the discretion of the chairs - only used where needed to
> clarify a problem statement for discussion.
>
> The sitting format is round-table.
>
> 2) BOFs (day 1)
>
> BOFs are sessions with a potential to become a workshop in a future
> Netdev conference. The lifetime of a BOF may be only one or two
> Netdev conference gatherings. We discourage perpetual BOFs.
> BoFs don't need to have an existing networking subsystem or mailing list.
> BOFs also don't need to strive to be upgraded to be a Workshop
> in the future. Their longevity could only be one conference.
> The sitting format could vary and be either lecture or round table format
> depending on the proposal.
>
> 3) Tutorials (day 2)
>
> Tutorials are generally about 2 hours long (or more at the discretion
> of the proposal).
> Tutorials are educational in nature and are presented in a classroom
> format with a specific educational outcome for the attendees.
>
> 4) Paper proposals (days 3 and 4)
>
> These are classical conference paper + presentations.
> Presentations are 30 minutes long with an additional 15 minutes for Q&A
> presented in a lecture format.
> We will require paper submissions for these sessions. The committee
> believes that a paper submission raises the quality of the presentations
> and makes it easier to build on presented ideas in the future.
>
> The Netdev conference this year is structured to be 50% by-invitation
> and 50% submission. We are making sure that we reach out to speakers
> who have interesting relevant topics because we recognize most of
> these folks would typically not be submitting papers to a conference.
> The invitation will be made by the technical committee to the individual
> speakers for workshop, paper and tutorial sessions.
Clarification is that the presenters will be split 50/50 invitation/submission
and that regular attendance is open to anyone and we will welcome anyone to
join the conference audience.
> This call for papers is for the 50% submission portion of the
> conference for paper submissions, tutorials and workshops.
> We *highly discourage* submission of recycled talks.
>
> Current technical focus topics include:
> - wireless
> - performance analysis, debugging and improvement
> - networking hardware and offload
> - netfilter
> - traffic control
> - different networking layers (L2/3, etc)
> - Internet of things
> - security
> - additional topics can be suggested
>
> Unlike other conferences, we are going to try and accommodate as many
> submissions as possible - but please stay within the relevant topic focus
> and tie to Linux networking to make it easier for the technical committee
> to provide quick feedback. In order to give a talk you must be
> registered. If your proposal is accepted you will not be charged
> a conference fee or your conference fee will be refunded to you
> when your talk gets accepted.
>
> We expect minimum of 2 parallel tracks but likely more depending on the
> (quantity of submissions) in all phases i.e during tutorials,
> workshops and main talks.
>
> Why you should submit a proposal
> ---------------------------------
> If you yearn for the old community tech driven conferences where
> you mingle with fellow geeks (only these would be Linux networking
> geeks) then this would be it. There will be no marketing flashy
> openings. There will just be a pure feed of Linux networking.
> Netdev 0.1 will be held back to back with Netconf 2015, the
> by-invite Linux kernel networking workshop
> (http://vger.kernel.org/netconf2015.html).
> So gurus of all sorts will be there mingling and giving talks.
> While there will be heavy Linux kernel influence we expect a lot
> of user space presence as well.
>
> How to submit a proposal
> ------------------------
> Send email to netdev01@lists.netfilter.org with a paragraph or
> two of your proposal.
> For paper proposals, if your submission is accepted we will provide
> you a template to use.
> A minimum of two pages is needed so as to to allow people to skip the
> burden of writing a large paper. The maximum page limit is 10 pages.
>
> Location:
> ---------
> Downtown Ottawa, Canada
> www.netdev01.org
>
> Important Dates:
> ----------------
> December 02, 2014 Call for Papers opens
> December 10, 2014 Registration opens
> January 10, 2015 Call for sessions deadline
> January 20, 2015 Conference schedule announced
> February 14-17, 2015 Conference days
>
> Please register as soon as registration opens up on December 10.
> Registering helps us plan properly for numbers of attendees,
> ensuring venue sizes and supplies are appropriate without
> wasting resources.
>
>
>
> slainte mhath, RGB
slainte mhath, RGB
--
Richard Guy Briggs -- ~\ -- ~\ <hpv.tricolour.ca>
<www.TriColour.ca> -- \___ o \@ @ Ride yer bike!
Ottawa, ON, CANADA -- Lo_>__M__\\/\%__\\/\%
Vote! -- <greenparty.ca>_____GTVS6#790__(*)__(*)________(*)(*)_________________
^ permalink raw reply
* Re: [PATCH v2 0/6] net-PPP: Deletion of a few unnecessary checks
From: SF Markus Elfring @ 2014-12-12 15:30 UTC (permalink / raw)
To: David Miller
Cc: Sergei Shtylyov, Paul Mackerras, linux-ppp, netdev, Eric Dumazet,
linux-kernel, kernel-janitors, Julia Lawall
In-Reply-To: <20141212.092950.1840808214143867233.davem@davemloft.net>
> I gave you very concrete feedback, I said exactly that I don't want
> error pointers left in data structure members.
I find that your critique affects the proposed update steps four to six,
doesn't it?
Are the other steps acceptable in principle?
> I cannot describe my requirements any more precisely than that.
I hope that a bit more constructive suggestions will be contributed by
involved
software developers around the affected source code. Now it seems
that a small code clean-up becomes a more challenging development task.
How do you prefer to redesign corresponding data structures eventually?
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v2 0/6] net-PPP: Deletion of a few unnecessary checks
From: David Miller @ 2014-12-12 15:51 UTC (permalink / raw)
To: elfring
Cc: sergei.shtylyov, paulus, linux-ppp, netdev, eric.dumazet,
linux-kernel, kernel-janitors, julia.lawall
In-Reply-To: <548B0A29.8050503@users.sourceforge.net>
You are asking me to invest a lot of time for a very trivial
set of changes.
Why don't you just integrate the feedback you were given and
resubmit your patch series, just like any other developer would?
^ permalink raw reply
* Re: [PATCH net-next] Avoid reducing cwnd when ACK+DSACK is received
From: Neal Cardwell @ 2014-12-12 15:54 UTC (permalink / raw)
To: Sébastien Barré
Cc: David Miller, Netdev, Gregory Detal, Nandita Dukkipati,
Yuchung Cheng
In-Reply-To: <1418327890-368-1-git-send-email-sebastien.barre@uclouvain.be>
On Thu, Dec 11, 2014 at 2:58 PM, Sébastien Barré
<sebastien.barre@uclouvain.be> wrote:
> When the peer has delayed ack enabled, it may reply to a probe with an
> ACK+D-SACK, with ack value set to tlp_high_seq. In the current code,
> such ACK+DSACK will be missed and only at next, higher ack will the TLP
> episode be considered done. Since the DSACK is not present anymore,
> this will cost a cwnd reduction.
>
> This patch ensures that this scenario does not cause a cwnd reduction, since
> receiving an ACK+DSACK indicates that both the initial segment and the probe
> have been received by the peer.
>
> Cc: Gregory Detal <gregory.detal@uclouvain.be>
> Cc: Nandita Dukkipati <nanditad@google.com>
> Cc: Yuchung Cheng <ycheng@google.com>
> Signed-off-by: Sébastien Barré <sebastien.barre@uclouvain.be>
BTW, I like this idea, and I'll test it.
Two suggestions for the next iteration:
(1) for TCP patch style, I'd suggest a commit first-line like:
tcp: avoid reducing cwnd when ACK+DSACK is received
(2) Your patch is essentially a reworking of the is_tlp_dupack
computation. So rather than splitting the logic between the
is_tlp_dupack computation and the new expression inside the if
condition, I'd suggest moving and centralizing all the logic in the if
condition. There is no real need for the is_tlp_dupack variable.
neal
^ permalink raw reply
* Re: [net PATCH] fib_trie: Fix trie balancing issue if new node pushes down existing node
From: David Miller @ 2014-12-12 15:54 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: netdev
In-Reply-To: <20141211.213216.1630491264342423219.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Thu, 11 Dec 2014 21:32:16 -0500 (EST)
> From: Alexander Duyck <alexander.h.duyck@redhat.com>
> Date: Wed, 10 Dec 2014 21:49:22 -0800
>
>> This patch addresses an issue with the level compression of the fib_trie.
>> Specifically in the case of adding a new leaf that triggers a new node to
>> be added that takes the place of the old node. The result is a trie where
>> the 1 child tnode is on one side and one leaf is on the other which gives
>> you a very deep trie. Below is the script I used to generate a trie on
>> dummy0 with a 10.X.X.X family of addresses.
> ...
>> What this fix does is start the rebalance at the newly created tnode
>> instead of at the parent tnode. This way if there is a gap between the
>> parent and the new node it doesn't prevent the new tnode from being
>> coalesced with any pre-existing nodes that may have been pushed into one
>> of the new nodes child branches.
>>
>> Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
>
> One has to be mindful with this code that what it's doing now might
> be intentional. For example, it might be doing things this way
> on purpose in order to minimize rebalancing during route flaps.
>
> Barring anything like that, I think your change is fine.
Alex, in case it isn't clear, I'm hoping that you might have some
thoughts on this aspect of your changes. :)
^ permalink raw reply
* Re: [net PATCH] fib_trie: Fix trie balancing issue if new node pushes down existing node
From: Alexander Duyck @ 2014-12-12 15:55 UTC (permalink / raw)
To: David Miller, alexander.h.duyck; +Cc: netdev
In-Reply-To: <20141211.213216.1630491264342423219.davem@davemloft.net>
On 12/11/2014 06:32 PM, David Miller wrote:
> From: Alexander Duyck <alexander.h.duyck@redhat.com>
> Date: Wed, 10 Dec 2014 21:49:22 -0800
>
>> This patch addresses an issue with the level compression of the fib_trie.
>> Specifically in the case of adding a new leaf that triggers a new node to
>> be added that takes the place of the old node. The result is a trie where
>> the 1 child tnode is on one side and one leaf is on the other which gives
>> you a very deep trie. Below is the script I used to generate a trie on
>> dummy0 with a 10.X.X.X family of addresses.
> ...
>> What this fix does is start the rebalance at the newly created tnode
>> instead of at the parent tnode. This way if there is a gap between the
>> parent and the new node it doesn't prevent the new tnode from being
>> coalesced with any pre-existing nodes that may have been pushed into one
>> of the new nodes child branches.
>>
>> Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
> One has to be mindful with this code that what it's doing now might
> be intentional. For example, it might be doing things this way
> on purpose in order to minimize rebalancing during route flaps.
>
> Barring anything like that, I think your change is fine.
I'm fairly certain that this isn't intentional. If we replace a NULL
pointer in an existing tnode then we rebalance starting at that tnode,
it is only when there is no room in the trie and we have to add a new
tnode that the issue occurs where we rebalance at the parent and not the
tnode that the leaf was added to.
- Alex
^ permalink raw reply
* [PATCH net] net: smc91x: Fix build without gpiolib
From: Tobias Klauser @ 2014-12-12 16:00 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: David S. Miller, Tony Lindgren, netdev
If GPIOLIB=n the following build error occurs:
Since the toggling of the GPIOs is an optional feature, define
try_toggle_control_gpio only if GPIOLIB is enabled.
Fixes: 7d2911c4381 ("net: smc91x: Fix gpios for device tree based booting")
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/net/ethernet/smsc/smc91x.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/smsc/smc91x.c b/drivers/net/ethernet/smsc/smc91x.c
index 6cc3cf6..050bcb6 100644
--- a/drivers/net/ethernet/smsc/smc91x.c
+++ b/drivers/net/ethernet/smsc/smc91x.c
@@ -2193,6 +2193,7 @@ MODULE_DEVICE_TABLE(of, smc91x_match);
/**
* of_try_set_control_gpio - configure a gpio if it exists
*/
+#ifdef CONFIG_GPIOLIB
static int try_toggle_control_gpio(struct device *dev,
struct gpio_desc **desc,
const char *name, int index,
@@ -2224,7 +2225,16 @@ static int try_toggle_control_gpio(struct device *dev,
return 0;
}
-#endif
+#else
+static int try_toggle_control_gpio(struct device *dev,
+ struct gpio_desc **desc,
+ const char *name, int index,
+ int value, unsigned int nsdelay)
+{
+ return 0;
+}
+#endif /* CONFIG_GPIOLIB */
+#endif /* CONFIG_OF */
/*
* smc_init(void)
--
2.2.0
^ permalink raw reply related
* Re: [net PATCH] fib_trie: Fix trie balancing issue if new node pushes down existing node
From: David Miller @ 2014-12-12 16:00 UTC (permalink / raw)
To: alexander.duyck; +Cc: alexander.h.duyck, netdev
In-Reply-To: <548B0FD6.8040105@gmail.com>
From: Alexander Duyck <alexander.duyck@gmail.com>
Date: Fri, 12 Dec 2014 07:55:02 -0800
> On 12/11/2014 06:32 PM, David Miller wrote:
>> From: Alexander Duyck <alexander.h.duyck@redhat.com>
>> Date: Wed, 10 Dec 2014 21:49:22 -0800
>>
>>> This patch addresses an issue with the level compression of the fib_trie.
>>> Specifically in the case of adding a new leaf that triggers a new node to
>>> be added that takes the place of the old node. The result is a trie where
>>> the 1 child tnode is on one side and one leaf is on the other which gives
>>> you a very deep trie. Below is the script I used to generate a trie on
>>> dummy0 with a 10.X.X.X family of addresses.
>> ...
>>> What this fix does is start the rebalance at the newly created tnode
>>> instead of at the parent tnode. This way if there is a gap between the
>>> parent and the new node it doesn't prevent the new tnode from being
>>> coalesced with any pre-existing nodes that may have been pushed into one
>>> of the new nodes child branches.
>>>
>>> Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
>> One has to be mindful with this code that what it's doing now might
>> be intentional. For example, it might be doing things this way
>> on purpose in order to minimize rebalancing during route flaps.
>>
>> Barring anything like that, I think your change is fine.
>
> I'm fairly certain that this isn't intentional. If we replace a NULL
> pointer in an existing tnode then we rebalance starting at that tnode,
> it is only when there is no room in the trie and we have to add a new
> tnode that the issue occurs where we rebalance at the parent and not the
> tnode that the leaf was added to.
Ok, thanks for taking the time to explain this, I'm now convinced :)
Applied, thanks again.
^ permalink raw reply
* Re: [PATCH net-next] vlan: Add ability to always enable TSO/UFO
From: David Miller @ 2014-12-12 16:01 UTC (permalink / raw)
To: makita.toshiaki; +Cc: kaber, netdev
In-Reply-To: <1418179394-4470-1-git-send-email-makita.toshiaki@lab.ntt.co.jp>
From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Date: Wed, 10 Dec 2014 11:43:13 +0900
> Since the real device can segment packets by software, a vlan device
> can set TSO/UFO even when the real device doesn't have those features.
> Unlike GSO, this allows packets to be segmented after Qdisc.
>
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Applied.
^ permalink raw reply
* Re: [PATCH] net: phy: export fixed_phy_register()
From: David Miller @ 2014-12-12 16:01 UTC (permalink / raw)
To: msalter; +Cc: f.fainelli, netdev, linux-kernel
In-Reply-To: <1418357006-2450-1-git-send-email-msalter@redhat.com>
From: Mark Salter <msalter@redhat.com>
Date: Thu, 11 Dec 2014 23:03:26 -0500
> When building the bcmgenet driver as module, I get:
>
> ERROR: "fixed_phy_register" [drivers/net/ethernet/broadcom/genet/genet.ko] undefined!
>
> commit b0ba512e225d72 ("net: bcmgenet: enable driver to work without device
> tree") which added a call to fixed_phy_register. But fixed_phy_register
> needs to be exported if used from a module.
>
> Signed-off-by: Mark Salter <msalter@redhat.com>
APplied.
^ permalink raw reply
* Re: randconfig build error with next-20141210, in drivers/net/ethernet/broadcom/genet
From: David Miller @ 2014-12-12 16:02 UTC (permalink / raw)
To: f.fainelli; +Cc: jim.epost, sfr, linux-next, linux-kernel, netdev
In-Reply-To: <548A786D.2060201@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Thu, 11 Dec 2014 21:09:01 -0800
> Le 11/12/2014 11:22, David Miller a écrit :
>> From: Jim Davis <jim.epost@gmail.com> Date: Wed, 10 Dec 2014
>> 09:10:45 -0700
>>
>>> Building with the attached random configuration file,
>>>
>>> ERROR: "fixed_phy_register"
>>> [drivers/net/ethernet/broadcom/genet/genet.ko] undefined!
>>
>> Florian, I don't understand why FIXED_PHY is only selected in
>> Kconfig if the driver is statically built into the kernel.
>>
>> That makes no sense at all, you should need that module regardless
>> of how the driver itself is enabled.
>
> AFAIR this was introduced to silence a warning you reported:
>
> "I think you need to work on the Kconfig dependencies a little bit more.
> I have BCMGENET specified as modular, which absolutely should work. Yet
> Kconfig complains.
>
> warning: (BCMGENET) selects FIXED_PHY which has unmet direct
> dependencies (NETDEVICES && PHYLIB=y)"
>
> but I agree, this makes no sense, we should select FIXED_PHY
> unconditionnally, will send you patches tomorrow to fix that.
What's really perplexing is that FIXED_PHY is only enable'able
when PHYLIB=y. I think that's the core of the problems here.
All of these drivers shouldn't lose fixed phy support simply
because they, or PHYLIB itself, is built modular.
^ permalink raw reply
* Re: [PATCH net] net: smc91x: Fix build without gpiolib
From: Tobias Klauser @ 2014-12-12 16:03 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: David S. Miller, Tony Lindgren, netdev
In-Reply-To: <1418400022-6264-1-git-send-email-tklauser@distanz.ch>
On 2014-12-12 at 17:00:22 +0100, Tobias Klauser <tklauser@distanz.ch> wrote:
> If GPIOLIB=n the following build error occurs:
Sorry, I forgot to paste the following error message here:
drivers/net/ethernet/smsc/smc91x.c: In function 'try_toggle_control_gpio':
drivers/net/ethernet/smsc/smc91x.c:2204:2: error: implicit declaration of function 'devm_gpiod_get_index' [-Werror=implicit-function-declaration]
drivers/net/ethernet/smsc/smc91x.c:2204:7: warning: assignment makes pointer from integer without a cast [enabled by default]
drivers/net/ethernet/smsc/smc91x.c:2213:2: error: implicit declaration of function 'gpiod_direction_output' [-Werror=implicit-function-declaration]
drivers/net/ethernet/smsc/smc91x.c:2216:3: error: implicit declaration of function 'devm_gpiod_put' [-Werror=implicit-function-declaration]
drivers/net/ethernet/smsc/smc91x.c:2222:2: error: implicit declaration of function 'gpiod_set_value_cansleep' [-Werror=implicit-function-declaration]
I'll send an updated patch. Please disregard this one.
^ permalink raw reply
* [PATCH net v2] net: smc91x: Fix build without gpiolib
From: Tobias Klauser @ 2014-12-12 16:07 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: David S. Miller, Tony Lindgren, netdev
If GPIOLIB=n the following build errors occur:
drivers/net/ethernet/smsc/smc91x.c: In function 'try_toggle_control_gpio':
drivers/net/ethernet/smsc/smc91x.c:2204:2: error: implicit declaration of function 'devm_gpiod_get_index' [-Werror=implicit-function-declaration]
drivers/net/ethernet/smsc/smc91x.c:2204:7: warning: assignment makes pointer from integer without a cast [enabled by default]
drivers/net/ethernet/smsc/smc91x.c:2213:2: error: implicit declaration of function 'gpiod_direction_output' [-Werror=implicit-function-declaration]
drivers/net/ethernet/smsc/smc91x.c:2216:3: error: implicit declaration of function 'devm_gpiod_put' [-Werror=implicit-function-declaration]
drivers/net/ethernet/smsc/smc91x.c:2222:2: error: implicit declaration of function 'gpiod_set_value_cansleep' [-Werror=implicit-function-declaration]
Since the toggling of the GPIOs is an optional feature, define
try_toggle_control_gpio only if GPIOLIB is enabled.
Fixes: 7d2911c4381 ("net: smc91x: Fix gpios for device tree based booting")
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/net/ethernet/smsc/smc91x.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/smsc/smc91x.c b/drivers/net/ethernet/smsc/smc91x.c
index 6cc3cf6..050bcb6 100644
--- a/drivers/net/ethernet/smsc/smc91x.c
+++ b/drivers/net/ethernet/smsc/smc91x.c
@@ -2193,6 +2193,7 @@ MODULE_DEVICE_TABLE(of, smc91x_match);
/**
* of_try_set_control_gpio - configure a gpio if it exists
*/
+#ifdef CONFIG_GPIOLIB
static int try_toggle_control_gpio(struct device *dev,
struct gpio_desc **desc,
const char *name, int index,
@@ -2224,7 +2225,16 @@ static int try_toggle_control_gpio(struct device *dev,
return 0;
}
-#endif
+#else
+static int try_toggle_control_gpio(struct device *dev,
+ struct gpio_desc **desc,
+ const char *name, int index,
+ int value, unsigned int nsdelay)
+{
+ return 0;
+}
+#endif /* CONFIG_GPIOLIB */
+#endif /* CONFIG_OF */
/*
* smc_init(void)
--
2.2.0
^ 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