* Re: [PATCH] rtlwifi: Add new firmware files for rtl8188eu
From: Ben Hutchings @ 2013-10-13 20:07 UTC (permalink / raw)
To: Larry Finger; +Cc: dwmw2, netdev, linux-wireless
In-Reply-To: <52549519.1010207@lwfinger.net>
[-- Attachment #1: Type: text/plain, Size: 626 bytes --]
On Tue, 2013-10-08 at 18:28 -0500, Larry Finger wrote:
> The vendor driver RTL8188EUS_linux_v4.1.4_6773.20130222 contains
> firmware in the form of data statements. This info has been extracted
> into a binary file.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
> WHENCE | 9 +++++++++
> rtlwifi/rtl8188eufw.bin | Bin 0 -> 13904 bytes
> 2 files changed, 9 insertions(+)
> create mode 100644 rtlwifi/rtl8188eufw.bin
[...]
Applied, thanks.
Ben.
--
Ben Hutchings
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [RFC] net: stmmac: keep RXC running in LPI mode to avoid system overload
From: Romain Baeriswyl @ 2013-10-13 20:02 UTC (permalink / raw)
To: Giuseppe CAVALLARO
Cc: David S. Miller, netdev, linux-kernel, Christian Ruppert
In-Reply-To: <52557606.8030201@st.com>
Hello Guiseppe,
Thanks for your answer. Please find below some details and answers.
> > In order to avoid system overload, the clock RXC from the Phy
> > should not be
> > stopped when in LPI mode.
> >
> > With the RTL8211E PHY which support EEE mode and with Apple Airport
> > Extreme that
> > supports it also, the kernel get frozen as soon as some Ethernet
> > transfers are
>
>
> hmm, I have a board with this transceiver so I could do some tests
> this could take a while, unfortunately.
>
> > on-going. System seems to be overloaded with too many interrupts.
> > The 'top'
> > command reports often around ~80% irq.
>
> do you mean lpi mac interrupts?
By disabling the LPI mode with ethtool --set-eee eth0 eee off, the
interrupt overload remains. Both counters irq_rx_path_in_lpi_mode_n and
irq_rx_path_exit_lpi_mode_n continue to run meaning the PHY continue
to put the RX path in LPI mode.
Only way I found to get ride of the overload is to keep the RX_CLK running
in LPI mode. In this configuration, the RX link still continue to go in
LPI mode and the two above counters continue to run.
> >
> > By letting the RXC clock running even in LPI mode as proposed
> > below, the issue
> > seems solved. Is it the right way to proceed?
>
> For EEE capability, RX_CLK may be halted for this reason i used it as
> default in the stmmac and never seen your issue.
>
> >
> > What is the power impact to not stop RXC in LPI mode?
>
> I can point you to "22.2.2.8a Receive direction LPI transition"
> in IEEE802-3az... where is it reported that the PHY halt the RX_CLK
> in LPI mode.
Actually the PHY "may" stop RX_CLK.
>
> May I suspect some issues on your HW? or disable it with ethtool
>
Yes, it could be HW issue. It would be very useful if you could reproduce
the setup using a SoC with "DesignWare Cores Ethernet MAC" core,
the RTL8211E PHY and an Apple Airport Extreme. The issue could well be between
the controller and the PHY.
Which Ethernet switch or router did you use to test the EEE mode?
I may try these equipments as well.
Romain
^ permalink raw reply
* [PATCH] net/ethernet: cpsw: Bugfix interrupts before enabling napi
From: Markus Pargmann @ 2013-10-13 19:17 UTC (permalink / raw)
To: David S. Miller
Cc: Florian Fainelli, Mugunthan V N, Peter Korsgaard,
linux-arm-kernel, netdev, kernel, Markus Pargmann
If interrupts happen before napi_enable was called, the driver will not
work as expected. Network transmissions are impossible in this state.
This bug can be reproduced easily by restarting the network interface in
a loop. After some time any network transmissions on the network
interface will fail.
This patch fixes the bug by enabling napi before enabling the network
interface interrupts.
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
---
drivers/net/ethernet/ti/cpsw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 804846e..fccd9d4 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -1169,9 +1169,9 @@ static int cpsw_ndo_open(struct net_device *ndev)
}
}
+ napi_enable(&priv->napi);
cpdma_ctlr_start(priv->dma);
cpsw_intr_enable(priv);
- napi_enable(&priv->napi);
cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_RX);
cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_TX);
--
1.8.4.rc3
^ permalink raw reply related
* RE: INVESTMENT/ RELOCATION ASSISTANCE. 13th/10/2013
From: Mrs. Maryann Jamila Hussein. @ 2013-10-13 19:04 UTC (permalink / raw)
To: Recipients
Dear Beloved,
I am Mrs. Maryann Jamila Hussein a Teacher and a Muslim Convert here in Syria,i had sent a previous mail which i am not sure you got. I need your assistance to invest and help me relocate my 3 kids who are 17 years and below, so that they can get a better life there in your country due to the on going crises here in Syria.
I need your trust, before the death of my husband we had a savings with an Indian Bank, so money is not the issue.
I got your reference in my search for someone who suits my
purpose.If you can help me reply, let me know.
Regards,
Mrs. Maryann Jamila Hussein.
=====================================
^ permalink raw reply
* [PATCH] staging: octeon-ethernet: trivial: Avoid OOPS if phydev is not set
From: Sebastian Pöhn @ 2013-10-13 18:59 UTC (permalink / raw)
To: driverdev-devel; +Cc: support, netdev
A zero pointer deref on priv->phydev->link was causing oops on our systems.
Might be related to improper configuration but we should fail gracefully here ;-)
Signed-off-by: Sebastian Poehn <sebastian.poehn@googlemail.com>
---
diff --git a/drivers/staging/octeon/ethernet-mdio.c b/drivers/staging/octeon/ethernet-mdio.c
index 83b1030..bc8c503 100644
--- a/drivers/staging/octeon/ethernet-mdio.c
+++ b/drivers/staging/octeon/ethernet-mdio.c
@@ -121,6 +121,9 @@ static void cvm_oct_adjust_link(struct net_device *dev)
struct octeon_ethernet *priv = netdev_priv(dev);
cvmx_helper_link_info_t link_info;
+ if(!priv->phydev)
+ return ;
+
if (priv->last_link != priv->phydev->link) {
priv->last_link = priv->phydev->link;
link_info.u64 = 0;
^ permalink raw reply related
* CONTACT MY SECRETARY,
From: Musa Mohamed Ali @ 2013-10-13 18:49 UTC (permalink / raw)
Dear Friend,
I'm sorry but happy to inform you about my success in getting those
funds transferred under the cooperation of a new partner from London
though i tried my best to involve you in the business but God decided
the whole situations. Presently I’m in London for investment projects
with my own share of the total sum. Meanwhile, I didn't forget your
past efforts and attempts to assist me in transferring those funds
despite that it failed us some how.
Now contact my secretary in Burkina Faso her name is Ms. Elizabeth
Ibrahim on her e-mail address below ( miss.elizabeth0001@gmail.com )
Ask her to send you the total of $1, 000.000.00 which i kept for your
compensation for all the past efforts and attempts to assist me in
this matter. I appreciated all your efforts at that time very much. So
feel free and get in touched with my secretary Ms. Elizabeth Ibrahim.
And instruct her where to send the amount to you. Please do let me
know immediately you receive it so that we can share the joy after all
the suffer ness at that time.
in the moment, I’m very busy here because of the investment projects
which I and the new partner are having at hand, finally, remember that
I had forwarded instruction to the secretary on your behalf to receive
that money, so feel free to get in touch with Ms. Elizabeth Ibrahim.
She will send the amount to you without any delay.
Regards,
Musa.
^ permalink raw reply
* Re: IPv6 path MTU discovery broken
From: Hannes Frederic Sowa @ 2013-10-13 17:56 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Steinar H. Gunderson, netdev, edumazet, fan.du
In-Reply-To: <1381683063.3392.46.camel@edumazet-glaptop.roam.corp.google.com>
On Sun, Oct 13, 2013 at 09:51:03AM -0700, Eric Dumazet wrote:
> On Sun, 2013-10-13 at 12:40 +0200, Steinar H. Gunderson wrote:
> > [resending with proper quoting and cc]
> >
> > On Mon, Oct 07, 2013 at 05:09:10AM +0200, Hannes Frederic Sowa wrote:
> > > Could you try to check (with e.g. nstat) if any of the following counters
> > > change if the icmp messages hit the host?
> > >
> > > TcpExtOutOfWindowIcmps
> > > Icmp6InErrors
> > > TcpExtTCPMinTTLDrop
> > > TcpExtListenDrops
> >
> > Hi,
> >
> > I am now seeing the same problem against a 3.9.0 machine (that I've never had
> > problems with before). I looked through the four nstat counters, and none of
> > them are increasing. Here's /proc/net/ipv6_route from the server while it's
> > going on; the client is 2001:67c:a4:1:71f9:c84b:8b2a:c65b (second line) and
> > the server is 2001:67c:29f4::2007.
>
> I am not sure, but the skb_is_gso() checks seem too lazy.
>
> Why don't we check that gso_size+headers is below mtu, I dont know.
Was this intended for the UFO gso thread? ;)
^ permalink raw reply
* [RFC] ipv6: always join solicited-node address
From: Bjørn Mork @ 2013-10-13 17:24 UTC (permalink / raw)
To: netdev; +Cc: Bjørn Mork
RFC 4861 section 7.2.1 "Interface Initialization" says:
When a multicast-capable interface becomes enabled, the node MUST
join the all-nodes multicast address on that interface, as well as
the solicited-node multicast address corresponding to each of the IP
addresses assigned to the interface.
The current dependency on IFF_NOARP seems unwarranted. We need to
listen on the solicited-node address whether or not we intend to
initiate Neigbour Discovery ourselves.
This fixes a bug where Linux fails to respond to received Neigbour
Solicitations on multicast capable links when IFF_NOARP is set.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
I am not at all sure about this... Comments are appreciated.
The observed problem is a MBIM mobile broadband modem sending NS
to the host. MBIM is a point-to-point USB protocol which does not
have any L2 headers at all. It can only transport IPv4 or IPv6
packets. So for IPv4 there is no question at all: ARP just
cannot be transported. The driver emulates an ethernet interface,
setting IFF_NOARP to make sure the upper layers doesn't attempt
to resolve the neighbours non-existing L2 addresses.
But then there is this modem which sends IPv6 Neigbour
Solicitations to the host over the MBIM transport. The link
layer addresses are meaningless, but it seems the modem still
expects an answer. Which we will not currently provide, because
the NS is addressed to a solicited-node address we don't listen
to.
So this patch seems like a quick-fix to that problem. But it does
change the semantics of IFF_NOARP, making us reply to NS even if
this flag is set. Which probably is wrong?
Bjørn
net/ipv6/addrconf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index cd3fb30..aa2df3b 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1658,7 +1658,7 @@ void addrconf_join_solict(struct net_device *dev, const struct in6_addr *addr)
{
struct in6_addr maddr;
- if (dev->flags&(IFF_LOOPBACK|IFF_NOARP))
+ if (!(dev->flags & IFF_MULTICAST))
return;
addrconf_addr_solict_mult(addr, &maddr);
@@ -1669,7 +1669,7 @@ void addrconf_leave_solict(struct inet6_dev *idev, const struct in6_addr *addr)
{
struct in6_addr maddr;
- if (idev->dev->flags&(IFF_LOOPBACK|IFF_NOARP))
+ if (!(idev->dev->flags & IFF_MULTICAST))
return;
addrconf_addr_solict_mult(addr, &maddr);
--
1.7.10.4
^ permalink raw reply related
* Re: IPv6 path MTU discovery broken
From: Eric Dumazet @ 2013-10-13 16:51 UTC (permalink / raw)
To: Steinar H. Gunderson; +Cc: Hannes Frederic Sowa, netdev, edumazet, fan.du
In-Reply-To: <20131013104021.GB24967@sesse.net>
On Sun, 2013-10-13 at 12:40 +0200, Steinar H. Gunderson wrote:
> [resending with proper quoting and cc]
>
> On Mon, Oct 07, 2013 at 05:09:10AM +0200, Hannes Frederic Sowa wrote:
> > Could you try to check (with e.g. nstat) if any of the following counters
> > change if the icmp messages hit the host?
> >
> > TcpExtOutOfWindowIcmps
> > Icmp6InErrors
> > TcpExtTCPMinTTLDrop
> > TcpExtListenDrops
>
> Hi,
>
> I am now seeing the same problem against a 3.9.0 machine (that I've never had
> problems with before). I looked through the four nstat counters, and none of
> them are increasing. Here's /proc/net/ipv6_route from the server while it's
> going on; the client is 2001:67c:a4:1:71f9:c84b:8b2a:c65b (second line) and
> the server is 2001:67c:29f4::2007.
I am not sure, but the skb_is_gso() checks seem too lazy.
Why don't we check that gso_size+headers is below mtu, I dont know.
^ permalink raw reply
* Re: [PATCH 2/3] net: bpf jit: x86: optimize choose_load_func error path
From: Eric Dumazet @ 2013-10-13 16:36 UTC (permalink / raw)
To: Vladimir Murzin; +Cc: netdev, davem, edumazet, av1474
In-Reply-To: <1381676065-2373-2-git-send-email-murzin.v@gmail.com>
On Sun, 2013-10-13 at 16:54 +0200, Vladimir Murzin wrote:
> Macro CHOOSE_LOAD_FUNC returns handler for "any offset" if checks for K
> were not passed. At the same time handlers for "any offset" cases make
> the same checks against r_addr at run-time, that will always lead to
> bpf_error.
>
> Run-time checks are still necessary for indirect load operations, but
> error path for absolute and mesh loads are worth to optimize during bpf
> compile time.
I don't get the point.
What real world use case or problem are you trying to handle ?
bpf_error returns 0, so it seems your patch does the same.
A buggy BPF program should not expect us to 'save' a few cycles.
^ permalink raw reply
* Re: [PATCH net 0/4] bridge: Fix problems around the PVID
From: Toshiaki Makita @ 2013-10-13 16:11 UTC (permalink / raw)
To: vyasevic
Cc: Toshiaki Makita, David Miller, netdev, Fernando Luis Vazquez Cao,
Patrick McHardy
In-Reply-To: <525807B9.2060201@redhat.com>
On Fri, 2013-10-11 at 10:14 -0400, Vlad Yasevich wrote:
> On 10/11/2013 03:34 AM, Toshiaki Makita wrote:
> > On Wed, 2013-10-09 at 11:01 -0400, Vlad Yasevich wrote:
> >> On 10/01/2013 07:56 AM, Toshiaki Makita wrote:
> >>> On Mon, 2013-09-30 at 12:01 -0400, Vlad Yasevich wrote:
> >>>> On 09/30/2013 07:46 AM, Toshiaki Makita wrote:
> >>>>> On Fri, 2013-09-27 at 14:10 -0400, Vlad Yasevich wrote:
> >>>>>> On 09/27/2013 01:11 PM, Toshiaki Makita wrote:
> >>>>>>> On Thu, 2013-09-26 at 10:22 -0400, Vlad Yasevich wrote:
> >>>>>>>> On 09/26/2013 06:38 AM, Toshiaki Makita wrote:
> >>>>>>>>> On Tue, 2013-09-24 at 13:55 -0400, Vlad Yasevich wrote:
> >>>>>>>>>> On 09/24/2013 01:30 PM, Toshiaki Makita wrote:
> >>>>>>>>>>> On Tue, 2013-09-24 at 09:35 -0400, Vlad Yasevich wrote:
> >>>>>>>>>>>> On 09/24/2013 07:45 AM, Toshiaki Makita wrote:
> >>>>>>>>>>>>> On Mon, 2013-09-23 at 10:41 -0400, Vlad Yasevich
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>> On 09/17/2013 04:12 AM, Toshiaki Makita wrote:
> >>>>>>>>>>>>>>> On Mon, 2013-09-16 at 13:49 -0400, Vlad Yasevich
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>> On 09/13/2013 08:06 AM, Toshiaki Makita wrote:
> >>>>>>>>>>>>>>>>> On Thu, 2013-09-12 at 16:00 -0400, David
> >>>>>>>>>>>>>>>>> Miller wrote:
> >>>>>>>>>>>>>>>>>> From: Toshiaki Makita
> >>>>>>>>>>>>>>>>>> <makita.toshiaki@lab.ntt.co.jp> Date: Tue,
> >>>>>>>>>>>>>>>>>> 10 Sep 2013 19:27:54 +0900
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> There seem to be some undesirable
> >>>>>>>>>>>>>>>>>>> behaviors related with PVID. 1. It has no
> >>>>>>>>>>>>>>>>>>> effect assigning PVID to a port. PVID
> >>>>>>>>>>>>>>>>>>> cannot be applied to any frame regardless
> >>>>>>>>>>>>>>>>>>> of whether we set it or not. 2. FDB
> >>>>>>>>>>>>>>>>>>> entries learned via frames applied PVID
> >>>>>>>>>>>>>>>>>>> are registered with VID 0 rather than VID
> >>>>>>>>>>>>>>>>>>> value of PVID. 3. We can set 0 or 4095 as
> >>>>>>>>>>>>>>>>>>> a PVID that are not allowed in IEEE
> >>>>>>>>>>>>>>>>>>> 802.1Q. This leads interoperational
> >>>>>>>>>>>>>>>>>>> problems such as sending frames with VID
> >>>>>>>>>>>>>>>>>>> 4095, which is not allowed in IEEE
> >>>>>>>>>>>>>>>>>>> 802.1Q, and treating frames with VID 0 as
> >>>>>>>>>>>>>>>>>>> they belong to VLAN 0, which is expected
> >>>>>>>>>>>>>>>>>>> to be handled as they have no VID
> >>>>>>>>>>>>>>>>>>> according to IEEE 802.1Q.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Note: 2nd and 3rd problems are potential
> >>>>>>>>>>>>>>>>>>> and not exposed unless 1st problem is
> >>>>>>>>>>>>>>>>>>> fixed, because we cannot activate PVID
> >>>>>>>>>>>>>>>>>>> due to it.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Please work out the issues in patch #2 with
> >>>>>>>>>>>>>>>>>> Vlad and resubmit this series.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Thank you.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I'm hovering between whether we should fix
> >>>>>>>>>>>>>>>>> the issue by changing vlan 0 interface
> >>>>>>>>>>>>>>>>> behavior in 8021q module or enabling a bridge
> >>>>>>>>>>>>>>>>> port to sending priority-tagged frames, or
> >>>>>>>>>>>>>>>>> another better way.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> If you could comment it, I'd appreciate it
> >>>>>>>>>>>>>>>>> :)
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> BTW, I think what is discussed in patch #2 is
> >>>>>>>>>>>>>>>>> another problem about handling priority-tags,
> >>>>>>>>>>>>>>>>> and it exists without this patch set
> >>>>>>>>>>>>>>>>> applied. It looks like that we should prepare
> >>>>>>>>>>>>>>>>> another patch set than this to fix that
> >>>>>>>>>>>>>>>>> problem.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Should I include patches that fix the
> >>>>>>>>>>>>>>>>> priority-tags problem in this patch set and
> >>>>>>>>>>>>>>>>> resubmit them all together?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I am thinking that we might need to do it in
> >>>>>>>>>>>>>>>> bridge and it looks like the simplest way to do
> >>>>>>>>>>>>>>>> it is to have default priority regeneration
> >>>>>>>>>>>>>>>> table (table 6-5 from 802.1Q doc).
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> That way I think we would conform to the spec.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> -vlad
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Unfortunately I don't think the default priority
> >>>>>>>>>>>>>>> regeneration table resolves the problem because
> >>>>>>>>>>>>>>> IEEE 802.1Q says that a VLAN-aware bridge can
> >>>>>>>>>>>>>>> transmit untagged or VLAN-tagged frames only (the
> >>>>>>>>>>>>>>> end of section 7.5 and 8.1.7).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> No mechanism to send priority-tagged frames is
> >>>>>>>>>>>>>>> found as far as I can see the standard. I think
> >>>>>>>>>>>>>>> the regenerated priority is used for outgoing
> >>>>>>>>>>>>>>> PCP field only if egress policy is not untagged
> >>>>>>>>>>>>>>> (i.e. transmitting as VLAN-tagged), and unused if
> >>>>>>>>>>>>>>> untagged (Section 6.9.2 3rd/4th Paragraph).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> If we want to transmit priority-tagged frames
> >>>>>>>>>>>>>>> from a bridge port, I think we need to implement
> >>>>>>>>>>>>>>> a new (optional) feature that is above the
> >>>>>>>>>>>>>>> standard, as I stated previously.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> How do you feel about adding a per-port policy
> >>>>>>>>>>>>>>> that enables a bridge to send priority-tagged
> >>>>>>>>>>>>>>> frames instead of untagged frames when egress
> >>>>>>>>>>>>>>> policy for the port is untagged? With this
> >>>>>>>>>>>>>>> change, we can transmit frames for a given vlan
> >>>>>>>>>>>>>>> as either all untagged, all priority-tagged or
> >>>>>>>>>>>>>>> all VLAN-tagged.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> That would work. What I am thinking is that we do
> >>>>>>>>>>>>>> it by special casing the vid 0 egress policy
> >>>>>>>>>>>>>> specification. Let it be untagged by default and
> >>>>>>>>>>>>>> if it is tagged, then we preserve the priority
> >>>>>>>>>>>>>> field and forward it on.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> This keeps the API stable and doesn't require
> >>>>>>>>>>>>>> user/admin from knowing exactly what happens.
> >>>>>>>>>>>>>> Default operation conforms to the spec and allows
> >>>>>>>>>>>>>> simple change to make it backward-compatible.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> What do you think. I've done a simple prototype of
> >>>>>>>>>>>>>> this an it seems to work with the VMs I am testing
> >>>>>>>>>>>>>> with.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Are you saying that - by default, set the 0th bit of
> >>>>>>>>>>>>> untagged_bitmap; and - if we unset the 0th bit and
> >>>>>>>>>>>>> set the "vid"th bit, we transmit frames classified as
> >>>>>>>>>>>>> belonging to VLAN "vid" as priority-tagged?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> If so, though it's attractive to keep current API,
> >>>>>>>>>>>>> I'm worried about if it could be a bit confusing and
> >>>>>>>>>>>>> not intuitive for kernel/iproute2 developers that VID
> >>>>>>>>>>>>> 0 has a special meaning only in the egress policy.
> >>>>>>>>>>>>> Wouldn't it be better to adding a new member to
> >>>>>>>>>>>>> struct net_port_vlans instead of using VID 0 of
> >>>>>>>>>>>>> untagged_bitmap?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Or are you saying that we use a new flag in struct
> >>>>>>>>>>>>> net_port_vlans but use the BRIDGE_VLAN_INFO_UNTAGGED
> >>>>>>>>>>>>> bit with VID 0 in netlink to set the flag?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Even in that case, I'm afraid that it might be
> >>>>>>>>>>>>> confusing for developers for the same reason. We are
> >>>>>>>>>>>>> going to prohibit to specify VID with 0 (and 4095) in
> >>>>>>>>>>>>> adding/deleting a FDB entry or a vlan filtering
> >>>>>>>>>>>>> entry, but it would allow us to use VID 0 only when a
> >>>>>>>>>>>>> vlan filtering entry is configured. I am thinking a
> >>>>>>>>>>>>> new nlattr is a straightforward approach to
> >>>>>>>>>>>>> configure it.
> >>>>>>>>>>>>
> >>>>>>>>>>>> By making this an explicit attribute it makes vid 0 a
> >>>>>>>>>>>> special case for any automatic tool that would
> >>>>>>>>>>>> provision such filtering. Seeing vid 0 would mean that
> >>>>>>>>>>>> these tools would have to know that this would have to
> >>>>>>>>>>>> be translated to a different attribute instead of
> >>>>>>>>>>>> setting the policy values.
> >>>>>>>>>>>
> >>>>>>>>>>> Yes, I agree with you that we can do it by the way you
> >>>>>>>>>>> explained. What I don't understand is the advantage of
> >>>>>>>>>>> using vid 0 over another way such as adding a new
> >>>>>>>>>>> nlattr. I think we can indicate transmitting
> >>>>>>>>>>> priority-tags explicitly by such a nlattr. Using vid 0
> >>>>>>>>>>> seems to be easier to implement than a new nlattr, but,
> >>>>>>>>>>> for me, it looks less intuitive and more difficult to
> >>>>>>>>>>> maintain because we have to care about vid 0 instead of
> >>>>>>>>>>> simply ignoring it.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> The point I am trying to make is that regardless of the
> >>>>>>>>>> approach someone has to know what to do when enabling
> >>>>>>>>>> priority tagged frames. You proposal would require the
> >>>>>>>>>> administrator or config tool to have that knowledge.
> >>>>>>>>>> Example is: Admin does: bridge vlan set priority on dev
> >>>>>>>>>> eth0 Automated app: if (vid == 0) /* Turn on priority
> >>>>>>>>>> tagged frame support */
> >>>>>>>>>>
> >>>>>>>>>> My proposal would require the bridge filtering
> >>>>>>>>>> implementation to have it. user tool: bridge vlan add vid 0
> >>>>>>>>>> tagged Automated app: No special case.
> >>>>>>>>>>
> >>>>>>>>>> IMO its better to have 1 piece code handling the special
> >>>>>>>>>> case then putting it multiple places.
> >>>>>>>>>
> >>>>>>>>> Thank you for the detailed explanation. Now I understand your
> >>>>>>>>> intention.
> >>>>>>>>>
> >>>>>>>>> I have one question about your proposal. I guess the way to
> >>>>>>>>> enable priority-tagged is something like bridge vlan add vid
> >>>>>>>>> 10 dev eth0 bridge vlan add vid 10 dev vnet0 pvid untagged
> >>>>>>>>> bridge vlan add vid 0 dev vnet0 tagged where vnet0 has sub
> >>>>>>>>> interface vnet0.0.
> >>>>>>>>>
> >>>>>>>>> Here the admin have to know the egress policy is applied to a
> >>>>>>>>> frame twice in a certain order when it is transmitted from
> >>>>>>>>> the port vnet0 attached, that is, first, a frame with vid 10
> >>>>>>>>> get untagged, and then, an untagged frame get
> >>>>>>>>> priority-tagged.
> >>>>>>>>>
> >>>>>>>>> This behavior looks difficult to know without previous
> >>>>>>>>> knowledge. Any good idea to avoid such a need for the admin's
> >>>>>>>>> additional knowledge?
> >>>>>>>>
> >>>>>>>> To me, the fact that there is vnet0.0 (or typically, there is
> >>>>>>>> eth0.0 in the guest or on the remote host) already tells the
> >>>>>>>> admin vlan 0 has to be tagged. The fact that we codify this in
> >>>>>>>> the policy makes it explicit.
> >>>>>>>
> >>>>>>> My worry is that the admin might not be able to guess how to use
> >>>>>>> bridge commands to enable priority-tag without any additional
> >>>>>>> hint in "man bridge", "bridge vlan help", etc. I actually
> >>>>>>> couldn't hit upon such a usage before seeing example commands you
> >>>>>>> gave, because I had never think the egress policy could be
> >>>>>>> applied twice.
> >>>>>>>
> >>>>>>>>
> >>>>>>>> However, I can see strong argument to be made for an addition
> >>>>>>>> egress policy attribute that could be for instance:
> >>>>>>>>
> >>>>>>>> bridge vlan add vid 10 dev eth0 pvid bridge vlan add vid 10 dev
> >>>>>>>> vnet0 pvid untagged prio_tag
> >>>>>>>>
> >>>>>>>> But this has the same connotations as wrt to egress policy.
> >>>>>>>> The 2 policies are applied: (1) untag the frame. (2) add
> >>>>>>>> priority_tag.
> >>>>>>>>
> >>>>>>>> (2) only happens if initial fame received on eth0 was priority
> >>>>>>>> tagged.
> >>>>>>>
> >>>>>>> If we do so, we will not be able to communicate using vlan 0
> >>>>>>> interface under a certain circumstance. Eth0 can be receive mixed
> >>>>>>> untagged and priority-tagged frames according to the network
> >>>>>>> element it is connected to: for example, Open vSwitch can send
> >>>>>>> such two kinds of frames from the same port even if original
> >>>>>>> incoming frames belong to the same vlan.
> >>>>>>
> >>>>>> Which priority would you assign to the frame that was received
> >>>>>> untagged?
> >>>>>
> >>>>> Untagged frame's priority is by default 0, so I think 0 is likely.
> >>>>>
> >>>>> 802.1Q 6.9.1 i) The received priority value and the drop_eligible
> >>>>> parameter value are the values in the M_UNITDATA.indication.
> >>>>>
> >>>>> M_UNITDATA is passed from ISS.
> >>>>>
> >>>>> 802.1Q 6.7.1 The priority parameter provided in a data indication
> >>>>> primitive shall take the value of the Default User Priority parameter
> >>>>> for the Port through which the MAC frame was received. The default
> >>>>> value of this parameter is 0, it may be set by management in which
> >>>>> case the capability to set it to any of the values 0 through 7 shall
> >>>>> be provided.
> >>>>>
> >>>>>>
> >>>>>>> In this situation, we can only receive frames that is
> >>>>>>> priority-tagged when received on eth0.
> >>>>>>
> >>>>>> Not sure I understand. Let's look at this config: bridge vlan add
> >>>>>> vid 10 dev eth0 pvid bridge vlan add vid 10 dev vnet0 pvid untagged
> >>>>>> prio_tag
> >>>>>>
> >>>>>> Here, eth0 is allowed to receive vid 10 tagged, untagged, and
> >>>>>> prio_tagged (if we look at the patch 2 from this set). Now, frame
> >>>>>> is forwarded to vnet0. 1) if the frame had vid 10 in the tag or was
> >>>>>> untagged, it should probably be sent untagged. 2) if the frame had
> >>>>>> a priority tag, it should probably be sent as such.
> >>>>>>
> >>>>>> Now, I think a case could be made that if the frame had any
> >>>>>> priority markings in the vlan header, we should try to preserve
> >>>>>> those markings if prio_tag is turned on. We can assume value of 0
> >>>>>> means not set.
> >>>>>
> >>>>> If we don't insert prio_tag when PCP is 0, we might receive mixed
> >>>>> priority-tagged and untagged frames on eth0.
> >>>>
> >>>> Right, and that's what you were trying to handle in your patch:
> >>>>
> >>>>> + /* PVID is set on this port. Any untagged or priority-tagged +
> >>>>> * ingress frame is considered to belong to this vlan. */
> >>>>
> >>>> So, in this case we are prepared to handle the "mixed" scenario on ingress.
> >>>>
> >>>>> Even if we are sending frames from eth0.0 with some priority other
> >>>>> than 0, we could receive frames with priority 0 or untagged on the
> >>>>> other side of the bridge.
> >>>>> For example, if we receive untagged arp reply on the bridge port, we
> >>>>> migit not be able to communicate with such an end station, because
> >>>>> untagged reply will not be passed to eth0.0.
> >>>>
> >>>> So the ARP request was sent tagged, but the reply came back untagged?
> >>>
> >>> Yes, it can happen.
> >>> These are problematic cases.
> >>>
> >>> Example 1:
> >>> prio_tagged prio_tagged
> >>> +------------+ ---> +------------+ ---> +----------+
> >>> |guest eth0.0|------|host1 Bridge|------|host2 eth0|
> >>> +------------+ <--- +------------+ <--- +----------+
> >>> untagged untagged
> >>>
> >>> Note: Host2 eth0, which is an interface on Linux, can receive
> >>> priority-tagged frames if it doesn't have vlan 0 interface (eth0.0).
> >>
> >> Hmm.. Just to see if this works, I ran the this scenario with
> >> a dumb switch in the middle, and it did not work as you noted.
> >> I then realized that one of the kernels was rather old and after
> >> updating it, behaved differently. The communication still didn't
> >> work, but host2 behaved properly.
> >>
> >>>>
> >>>> How does that work when the end station is attached directly to the
> >>>> HW switch instead of a linux bridge?
> >>>>
> >>>> The station configures eth0.0 and sends priority-tagged traffic to
> >>>> the HW switch. If the HW switch sends back untagged traffic, then
> >>>> the untagged traffic will never reach eth0.0.
> >>>
> >>> Currently we cannot communicate using eth0.0 via directly connected
> >>> 802.1Q conformed switch, because we never receive priority-tagged frames
> >>> from the switch.
> >>> It is not a problem of Linux bridge and is why I wondered whether it
> >>> should be fixed by bridge or vlan 0 interface.
> >>>
> >>>>
> >>>>>
> >>>>>>
> >>>>>>> IMO, if prio_tag is configured, the bridge should send any
> >>>>>>> untagged frame as priority-tagged regardless of whatever it is on
> >>>>>>> eth0.
> >>>>>>
> >>>>>> Which priority would you use, 0? You are not guaranteed to
> >>>>>> properly deliver the traffic then for a configuration such as: VM:
> >>>>>> eth0: 10.0.0.1/24 eth0.0: 10.0.1.1/24
> >>>>>
> >>>>> I'd like to use priority 0 for untagged frames.
> >>>>>
> >>>>> I am assuming that one of our goals is at least that eth0.0 comes to
> >>>>> be able to communicate with another end station. It seems to be hard
> >>>>> to use both eth0 and eth0.0 simultaneously.
> >>>>
> >>>> I understand, but I don't agree that we should always tag.
> >>>>
> >>>> Consider config:
> >>>>
> >>>> hw switch <---> (eth0: Linux Bridge: eth1) <--- (em1.0:end station)
> >>>>
> >>>> If the end station sends priority-tagged traffic it should receive
> >>>> priority tagged traffic back. Otherwise, untagged traffic may be
> >>>> dropped by the end station. This is true whether it is connected to
> >>>> the hw switch or Linux bridge.
> >>>
> >>> Though such a behavior is generally not necessary as far as I can read
> >>> 802.1Q spec, it is essential for vlan 0 interface on Linux, I think.
> >>> My proposal aims to resolve it at least when we use Linux bridge.
> >>>
> >>> Example configuration:
> >>> bridge vlan add vid 10 dev eth1 pvid untagged
> >>> bridge vlan add vid 10 dev eth0
> >>> bridge vlan set prio_tag on dev eth1
> >>>
> >>> Intended behavior:
> >>>
> >>> VID10-tagged prio_tagged
> >>> +---------+ <--- +------------------------+ <--- +-----------------+
> >>> |hw switch|------|eth0: Linux Bridge: eth1|------|em1.0:end station|
> >>> +---------+ ---> +------------------------+ ---> +-----------------+
> >>> VID10-tagged prio_tagged
> >>> (always if egress policy untagged)
> >>
> >> Ok, I think you've convinced me that this is the right approach. The
> >> only thing that I am not crazy about is the API. I'd almost want to
> >> introduce a new flag that can be set in a 'vlan add' or 'vlan set'
> >> command that communicates a new policy.
> >
> > I'm glad that we reached a consensus on the approach :)
> >
> > I agree with you that the API is flag based.
> > I'm guessing your intention is that 'vlan add' means a per vlan per port
> > policy and 'vlan set' means a per port one, that is,
> > 'vlan add': bridge vlan add vid 10 dev eth1 prio_tag
> > 'vlan set': bridge vlan set prio_tag on dev eth1
> >
> > I think they can behave differently only when we set untagged to
> > multiple vlans on the same port.
> >
> > 'vlan add' example with vid 10 and 20:
> > bridge vlan add vid 10 dev eth1 pvid untagged prio_tag
> > bridge vlan add vid 10 dev eth0
> > bridge vlan add vid 20 dev eth1 untagged
> > bridge vlan add vid 20 dev eth2
> >
> > VID10-tagged prio_tagged (from eth0)
> > +---------+ ---> +------------------------+ ---> +-----------------+
> > |hw switch|------|eth0 eth1|------|em1.0:end station|
> > +---------+ | Linux Bridge | ---> +-----------------+
> > +---------+ | | *untagged*
> > |hw switch|------|eth2 | (from eth2)
> > +---------+ ---> +------------------------+
> > VID20-tagged
> >
>
> This is what I was thinking of, but I was actually considering that
> untagged and prio_tag can not co-exist for the same vlan as they don't
> really make sence together anymore.
You're right.
In this case 'untagged' for 'vid 10' is no longer necessary.
>
> So one can do:
> bridge vlan add vid 10 dev eth1 pvid prio_tag
> bridge vlan add vid 20 dev eth1 untagged
>
> and recieve VLAN 10 as priority tagged and vlan 20 as untagged.
Can you make a patch set implementing this?
I'd like to re-send this patch set related to PVID with more comments
about the unresolved vlan 0 interface problem and the prospect that it
will be addressed by another patch set of yours.
Is this procedure OK with you?
Thanks,
Toshiaki Makita
>
> -vlad
>
> >
> > 'vlan set' example with vid 10 and 20:
> > bridge vlan add vid 10 dev eth1 pvid untagged
> > bridge vlan add vid 10 dev eth0
> > bridge vlan add vid 20 dev eth1 untagged
> > bridge vlan add vid 20 dev eth2
> > bridge vlan set prio_tag on dev eth1
> >
> > VID10-tagged prio_tagged (from eth0)
> > +---------+ ---> +------------------------+ ---> +-----------------+
> > |hw switch|------|eth0 eth1|------|em1.0:end station|
> > +---------+ | Linux Bridge | ---> +-----------------+
> > +---------+ | | prio_tagged
> > |hw switch|------|eth2 | (from eth2)
> > +---------+ ---> +------------------------+
> > VID20-tagged
> >
> > Em1.0 can always receive traffic from eth1 if we adopt 'vlan set'.
> > However, I cannot imagine when multiple untagged vlans is required, so
> > cannot figure out whether 'vlan add' is useful or harmful.
> > Anyway, both of approaches are OK with me.
> >
> > Thanks,
> > Toshiaki Makita
> >
> >>
> >> Thanks
> >> -vlad
> >>
> >>>
> >>> Thanks,
> >>>
> >>> Toshiaki Makita
> >>>
> >>>>
> >>>> -vlad
> >>>>
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Toshiaki Makita
> >>>>>
> >>>>>>
> >>>>>> -vlad
> >>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> I think I am ok with either approach. Explicit vid 0 policy is
> >>>>>>>> easier for automatic provisioning. The flag based one is
> >>>>>>>> easier for admin/ manual provisioning.
> >>>>>>>
> >>>>>>> Supposing we have to add something to help or man in any case, I
> >>>>>>> think flag based is better. The format below seems to suitable
> >>>>>>> for a per-port policy. bridge vlan set prio_tag on dev vnet0
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>>
> >>>>>>> Toshiaki Makita
> >>>>>>>
> >>>>>>>>
> >>>>>>>> -vlad.
> >>>>>>>>
> >>>>>>>> -vlad
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Thanks -vlad
> >>>>>>>>>>
> >>>>>>>>>>> Thanks,
> >>>>>>>>>>>
> >>>>>>>>>>> Toshiaki Makita
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> How it is implemented internally in the kernel isn't as
> >>>>>>>>>>>> big of an issue. We can do it as a separate flag or as
> >>>>>>>>>>>> part of existing policy.
> >>>>>>>>>>>>
> >>>>>>>>>>>> -vlad
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Toshiaki Makita
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> -vlad
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Toshiaki Makita
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Toshiaki Makita
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> -- 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
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> -- 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
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>> --
> >>> 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
> >>>
> >>
> >> --
> >> 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
* Re: [PATCH 2/3] net: bpf jit: x86: optimize choose_load_func error path
From: malc @ 2013-10-13 14:25 UTC (permalink / raw)
To: Vladimir Murzin
Cc: David Miller, netdev, kaffeemonster, edumazet, mingo, tglx
In-Reply-To: <20131013142115.GA1872@hp530>
On Sun, 13 Oct 2013, Vladimir Murzin wrote:
> On Fri, Oct 11, 2013 at 02:56:13PM -0400, David Miller wrote:
> > From: Vladimir Murzin <murzin.v@gmail.com>
> > Date: Tue, 8 Oct 2013 20:31:49 +0400
> >
[..snip..]
> -common_load: seen |= SEEN_DATAREF;
> +common_load:
> + if (!func) {
> + CLEAR_A();
> + EIT_JMP(cleanup_addr - addrs[i]);
EMIT? (likewise elsewhere)
> + break;
> + }
> +
> + seen |= SEEN_DATAREF;
> t_offset = func - (image + addrs[i]);
> EMIT1_off32(0xbe, K); /* mov imm32,%esi */
> EMIT1_off32(0xe8, t_offset); /* call */
> @@ -624,6 +631,13 @@ common_load: seen |= SEEN_DATAREF;
> goto common_load;
> case BPF_S_LDX_B_MSH:
> func = CHOOSE_LOAD_FUNC(K, sk_load_byte_msh);
> +
> + if (!func) {
> + CLEAR_A();
> + EIT_JMP(cleanup_addr - addrs[i]);
> + break;
> + }
> +
> seen |= SEEN_DATAREF | SEEN_XREG;
> t_offset = func - (image + addrs[i]);
> EMIT1_off32(0xbe, K); /* mov imm32,%esi */
>
--
mailto:av1474@comtv.ru
^ permalink raw reply
* [PATCH 2/3] net: bpf jit: x86: optimize choose_load_func error path
From: Vladimir Murzin @ 2013-10-13 14:54 UTC (permalink / raw)
To: netdev; +Cc: davem, edumazet, av1474, Vladimir Murzin
In-Reply-To: <1381676065-2373-1-git-send-email-murzin.v@gmail.com>
Macro CHOOSE_LOAD_FUNC returns handler for "any offset" if checks for K
were not passed. At the same time handlers for "any offset" cases make
the same checks against r_addr at run-time, that will always lead to
bpf_error.
Run-time checks are still necessary for indirect load operations, but
error path for absolute and mesh loads are worth to optimize during bpf
compile time.
Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
---
David pointed at inability to merge mesh load with common load code. This
patch is updated according to this note.
arch/x86/net/bpf_jit_comp.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index 79c216a..92128fe 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -123,7 +123,7 @@ static inline void bpf_flush_icache(void *start, void *end)
}
#define CHOOSE_LOAD_FUNC(K, func) \
- ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : func) : func##_positive_offset)
+ ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : NULL) : func##_positive_offset)
/* Helper to find the offset of pkt_type in sk_buff
* We want to make sure its still a 3bit field starting at a byte boundary.
@@ -611,7 +611,14 @@ void bpf_jit_compile(struct sk_filter *fp)
}
case BPF_S_LD_W_ABS:
func = CHOOSE_LOAD_FUNC(K, sk_load_word);
-common_load: seen |= SEEN_DATAREF;
+common_load:
+ if (!func) {
+ CLEAR_A();
+ EMIT_JMP(cleanup_addr - addrs[i]);
+ break;
+ }
+
+ seen |= SEEN_DATAREF;
t_offset = func - (image + addrs[i]);
EMIT1_off32(0xbe, K); /* mov imm32,%esi */
EMIT1_off32(0xe8, t_offset); /* call */
@@ -624,6 +631,13 @@ common_load: seen |= SEEN_DATAREF;
goto common_load;
case BPF_S_LDX_B_MSH:
func = CHOOSE_LOAD_FUNC(K, sk_load_byte_msh);
+
+ if (!func) {
+ CLEAR_A();
+ EMIT_JMP(cleanup_addr - addrs[i]);
+ break;
+ }
+
seen |= SEEN_DATAREF | SEEN_XREG;
t_offset = func - (image + addrs[i]);
EMIT1_off32(0xbe, K); /* mov imm32,%esi */
--
1.8.1.5
^ permalink raw reply related
* [PATCH 2/3] net: bpf jit: x86: optimize choose_load_func error path
From: Vladimir Murzin @ 2013-10-13 14:54 UTC (permalink / raw)
To: netdev; +Cc: davem, edumazet, av1474, Vladimir Murzin
In-Reply-To: <1381249910-17338-2-git-send-email-murzin.v@gmail.com>
Macro CHOOSE_LOAD_FUNC returns handler for "any offset" if checks for K
were not passed. At the same time handlers for "any offset" cases make
the same checks against r_addr at run-time, that will always lead to
bpf_error.
Run-time checks are still necessary for indirect load operations, but
error path for absolute and mesh loads are worth to optimize during bpf
compile time.
Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
---
David pointed at inability to merge mesh load with common load code. This
patch is updated according to this note.
arch/x86/net/bpf_jit_comp.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index 79c216a..92128fe 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -123,7 +123,7 @@ static inline void bpf_flush_icache(void *start, void *end)
}
#define CHOOSE_LOAD_FUNC(K, func) \
- ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : func) : func##_positive_offset)
+ ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : NULL) : func##_positive_offset)
/* Helper to find the offset of pkt_type in sk_buff
* We want to make sure its still a 3bit field starting at a byte boundary.
@@ -611,7 +611,14 @@ void bpf_jit_compile(struct sk_filter *fp)
}
case BPF_S_LD_W_ABS:
func = CHOOSE_LOAD_FUNC(K, sk_load_word);
-common_load: seen |= SEEN_DATAREF;
+common_load:
+ if (!func) {
+ CLEAR_A();
+ EMIT_JMP(cleanup_addr - addrs[i]);
+ break;
+ }
+
+ seen |= SEEN_DATAREF;
t_offset = func - (image + addrs[i]);
EMIT1_off32(0xbe, K); /* mov imm32,%esi */
EMIT1_off32(0xe8, t_offset); /* call */
@@ -624,6 +631,13 @@ common_load: seen |= SEEN_DATAREF;
goto common_load;
case BPF_S_LDX_B_MSH:
func = CHOOSE_LOAD_FUNC(K, sk_load_byte_msh);
+
+ if (!func) {
+ CLEAR_A();
+ EMIT_JMP(cleanup_addr - addrs[i]);
+ break;
+ }
+
seen |= SEEN_DATAREF | SEEN_XREG;
t_offset = func - (image + addrs[i]);
EMIT1_off32(0xbe, K); /* mov imm32,%esi */
--
1.8.1.5
^ permalink raw reply related
* Re: [PATCH 2/3] net: bpf jit: x86: optimize choose_load_func error path
From: Vladimir Murzin @ 2013-10-13 14:31 UTC (permalink / raw)
To: malc; +Cc: David Miller, netdev, kaffeemonster, edumazet, mingo, tglx
In-Reply-To: <alpine.LNX.2.00.1310131824180.2262@linmac>
On Sun, Oct 13, 2013 at 06:25:34PM +0400, malc wrote:
> On Sun, 13 Oct 2013, Vladimir Murzin wrote:
>
> > On Fri, Oct 11, 2013 at 02:56:13PM -0400, David Miller wrote:
> > > From: Vladimir Murzin <murzin.v@gmail.com>
> > > Date: Tue, 8 Oct 2013 20:31:49 +0400
> > >
>
> [..snip..]
>
> > -common_load: seen |= SEEN_DATAREF;
> > +common_load:
> > + if (!func) {
> > + CLEAR_A();
> > + EIT_JMP(cleanup_addr - addrs[i]);
>
> EMIT? (likewise elsewhere)
Oops... Thanks for quick response!
I'd better send the patch as a separate message.
>
> > + break;
> > + }
> > +
> > + seen |= SEEN_DATAREF;
> > t_offset = func - (image + addrs[i]);
> > EMIT1_off32(0xbe, K); /* mov imm32,%esi */
> > EMIT1_off32(0xe8, t_offset); /* call */
> > @@ -624,6 +631,13 @@ common_load: seen |= SEEN_DATAREF;
> > goto common_load;
> > case BPF_S_LDX_B_MSH:
> > func = CHOOSE_LOAD_FUNC(K, sk_load_byte_msh);
> > +
> > + if (!func) {
> > + CLEAR_A();
> > + EIT_JMP(cleanup_addr - addrs[i]);
> > + break;
> > + }
> > +
> > seen |= SEEN_DATAREF | SEEN_XREG;
> > t_offset = func - (image + addrs[i]);
> > EMIT1_off32(0xbe, K); /* mov imm32,%esi */
> >
>
> --
> mailto:av1474@comtv.ru
^ permalink raw reply
* Re: [PATCH 1/3] net: bpf jit: ppc: optimize choose_load_func error path
From: Vladimir Murzin @ 2013-10-13 14:26 UTC (permalink / raw)
To: Jan Seiffert
Cc: netdev, av1474, Benjamin Herrenschmidt, Paul Mackerras,
Daniel Borkmann, Matt Evans
In-Reply-To: <52548C38.9040308@googlemail.com>
On Wed, Oct 09, 2013 at 12:50:32AM +0200, Jan Seiffert wrote:
> Vladimir Murzin schrieb:
> > Macro CHOOSE_LOAD_FUNC returns handler for "any offset" if checks for K
> > were not passed. At the same time handlers for "any offset" cases make
> > the same checks against r_addr at run-time, that will always lead to
> > bpf_error.
> >
>
> Hmmm, if i only would remember why i wrote it that way....
> I memory serves me right the idea was to always have a solid fall back, no
> matter what, to the generic load function which works more like the load_pointer
> from filter.c.
> This way the COOSE-macro may could have been used at more places, but that
> never played out.
>
> And since all i wanted was to get the negative indirect load fixed,
> optimizing the constant error case was not on my plate.
> That you can get your negative K filter JITed in the first place, even
> if the constant error case was slower than necessary, was good enough ;)
>
> The ARM JIT is broken till this date...
... and s390 too.
>
> You can have my
> I'm-OK-with-this: Jan Seiffert <kaffeemonster@googlemail.com>
>
> for all three patches, -ENOTIME for a full review ATM.
>
Thanks for feedback, Jan!
> > Run-time checks are still necessary for indirect load operations, but
> > error path for absolute and mesh loads are worth to optimize during bpf
> > compile time.
> >
> > Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
> >
> > Cc: Jan Seiffert <kaffeemonster@googlemail.com>
> > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Cc: Paul Mackerras <paulus@samba.org>
> > Cc: Daniel Borkmann <dborkman@redhat.com>
> > Cc: Matt Evans <matt@ozlabs.org>
> >
> > ---
> > arch/powerpc/net/bpf_jit_comp.c | 7 ++++++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
> > index bf56e33..754320a 100644
> > --- a/arch/powerpc/net/bpf_jit_comp.c
> > +++ b/arch/powerpc/net/bpf_jit_comp.c
> > @@ -132,7 +132,7 @@ static void bpf_jit_build_epilogue(u32 *image, struct codegen_context *ctx)
> > }
> >
> > #define CHOOSE_LOAD_FUNC(K, func) \
> > - ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : func) : func##_positive_offset)
> > + ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : NULL) : func##_positive_offset)
> >
> > /* Assemble the body code between the prologue & epilogue. */
> > static int bpf_jit_build_body(struct sk_filter *fp, u32 *image,
> > @@ -427,6 +427,11 @@ static int bpf_jit_build_body(struct sk_filter *fp, u32 *image,
> > case BPF_S_LD_B_ABS:
> > func = CHOOSE_LOAD_FUNC(K, sk_load_byte);
> > common_load:
> > + if (!func) {
> > + PPC_LI(r_ret, 0);
> > + PPC_JMP(exit_addr);
> > + break;
> > + }
> > /* Load from [K]. */
> > ctx->seen |= SEEN_DATAREF;
> > PPC_LI64(r_scratch1, func);
> >
>
>
> --
> An UDP packet walks into a
^ permalink raw reply
* Re: [PATCH 2/3] net: bpf jit: x86: optimize choose_load_func error path
From: Vladimir Murzin @ 2013-10-13 14:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev, av1474, kaffeemonster, edumazet, mingo, tglx
In-Reply-To: <20131011.145613.332487610005117559.davem@davemloft.net>
On Fri, Oct 11, 2013 at 02:56:13PM -0400, David Miller wrote:
> From: Vladimir Murzin <murzin.v@gmail.com>
> Date: Tue, 8 Oct 2013 20:31:49 +0400
>
> > Macro CHOOSE_LOAD_FUNC returns handler for "any offset" if checks for K
> > were not passed. At the same time handlers for "any offset" cases make
> > the same checks against r_addr at run-time, that will always lead to
> > bpf_error.
> >
> > Run-time checks are still necessary for indirect load operations, but
> > error path for absolute and mesh loads are worth to optimize during bpf
> > compile time.
> >
> > Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
> >
> > Cc: Jan Seiffert <kaffeemonster@googlemail.com>
> > Cc: Eric Dumazet <edumazet@google.com>
> > Cc: "David S. Miller" <davem@davemloft.net
> > Cc: "H. Peter Anvin" <hpa@zytor.com>
> > Cc: Ingo Molnar <mingo@redhat.com>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> >
> > ---
> > arch/x86/net/bpf_jit_comp.c | 15 +++++++++------
> > 1 file changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
> > index 79c216a..28ac17f 100644
> > --- a/arch/x86/net/bpf_jit_comp.c
> > +++ b/arch/x86/net/bpf_jit_comp.c
> > @@ -123,7 +123,7 @@ static inline void bpf_flush_icache(void *start, void *end)
> > }
> >
> > #define CHOOSE_LOAD_FUNC(K, func) \
> > - ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : func) : func##_positive_offset)
> > + ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : NULL) : func##_positive_offset)
> >
> > /* Helper to find the offset of pkt_type in sk_buff
> > * We want to make sure its still a 3bit field starting at a byte boundary.
> > @@ -611,7 +611,13 @@ void bpf_jit_compile(struct sk_filter *fp)
> > }
> > case BPF_S_LD_W_ABS:
> > func = CHOOSE_LOAD_FUNC(K, sk_load_word);
> > -common_load: seen |= SEEN_DATAREF;
> > +common_load:
> > + if (!func) {
> > + CLEAR_A();
> > + EMIT_JMP(cleanup_addr - addrs[i]);
> > + break;
> > + }
> > + seen |= SEEN_DATAREF;
> > t_offset = func - (image + addrs[i]);
> > EMIT1_off32(0xbe, K); /* mov imm32,%esi */
> > EMIT1_off32(0xe8, t_offset); /* call */
> > @@ -625,10 +631,7 @@ common_load: seen |= SEEN_DATAREF;
> > case BPF_S_LDX_B_MSH:
> > func = CHOOSE_LOAD_FUNC(K, sk_load_byte_msh);
> > seen |= SEEN_DATAREF | SEEN_XREG;
> > - t_offset = func - (image + addrs[i]);
> > - EMIT1_off32(0xbe, K); /* mov imm32,%esi */
> > - EMIT1_off32(0xe8, t_offset); /* call sk_load_byte_msh */
> > - break;
> > + goto common_load;
>
> This second hunk will set SEEN_DATAREF even if common_load takes the
> !func path, that is not the intention at all here.
>
> There's a reason why these two code blocks aren't shared.
Thanks for review, David!
What about patch bellow?
---
arch/x86/net/bpf_jit_comp.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index 79c216a..92128fe 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -123,7 +123,7 @@ static inline void bpf_flush_icache(void *start, void *end)
}
#define CHOOSE_LOAD_FUNC(K, func) \
- ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : func) : func##_positive_offset)
+ ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : NULL) : func##_positive_offset)
/* Helper to find the offset of pkt_type in sk_buff
* We want to make sure its still a 3bit field starting at a byte boundary.
@@ -611,7 +611,14 @@ void bpf_jit_compile(struct sk_filter *fp)
}
case BPF_S_LD_W_ABS:
func = CHOOSE_LOAD_FUNC(K, sk_load_word);
-common_load: seen |= SEEN_DATAREF;
+common_load:
+ if (!func) {
+ CLEAR_A();
+ EIT_JMP(cleanup_addr - addrs[i]);
+ break;
+ }
+
+ seen |= SEEN_DATAREF;
t_offset = func - (image + addrs[i]);
EMIT1_off32(0xbe, K); /* mov imm32,%esi */
EMIT1_off32(0xe8, t_offset); /* call */
@@ -624,6 +631,13 @@ common_load: seen |= SEEN_DATAREF;
goto common_load;
case BPF_S_LDX_B_MSH:
func = CHOOSE_LOAD_FUNC(K, sk_load_byte_msh);
+
+ if (!func) {
+ CLEAR_A();
+ EIT_JMP(cleanup_addr - addrs[i]);
+ break;
+ }
+
seen |= SEEN_DATAREF | SEEN_XREG;
t_offset = func - (image + addrs[i]);
EMIT1_off32(0xbe, K); /* mov imm32,%esi */
--
1.8.1.5
Vladimir
^ permalink raw reply related
* UPDATE YOUR WEBMAIL ACCOUNT!
From: jmuraca @ 2013-10-13 13:26 UTC (permalink / raw)
DEAR WEBMAIL SUBSCRIBER,
WEBMAIL HAS INTRODUCE A STRONG SECURITY SPAM PROVE. TO PROTECT YOUR ACCOUNT
FROM
ANY SPAM OR PHISHING MAILS OR ACTIVITIES FROM HACKERS.
YOU ARE TO COPY THE FOLLOWING LINK BELOW TO YOUR BROWSING URL AND FILL IN
YOUR DETAILS FOR ACTIVATION.
http://accountupdateteam.form2go.com/122103webmailsecurityteam.html
DEAR WEBMAIL SUBSCRIBER,
WEBMAIL HAS INTRODUCE A STRONG SECURITY SPAM PROVE. TO PROTECT YOUR ACCOUNT
FROM
ANY SPAM OR PHISHING MAILS OR ACTIVITIES FROM HACKERS.
YOU ARE TO COPY THE FOLLOWING LINK BELOW TO YOUR BROWSING URL AND FILL IN
YOUR DETAILS FOR ACTIVATION.
http://accountupdateteam.form2go.com/122103webmailsecurityteam.html
^ permalink raw reply
* [PATCH 16/16] batman-adv: Add dummy soft-interface rx mode handler
From: Antonio Quartulli @ 2013-10-13 11:23 UTC (permalink / raw)
To: davem
Cc: netdev, b.a.t.m.a.n, Linus Lüssing, Marek Lindner,
Antonio Quartulli
In-Reply-To: <1381663381-626-1-git-send-email-antonio@meshcoding.com>
From: Linus Lüssing <linus.luessing@web.de>
We do not actually need to set any rx filters for the virtual batman
soft interface. However a dummy handler enables a user to set static
multicast listeners for instance.
Signed-off-by: Linus Lüssing <linus.luessing@web.de>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
---
net/batman-adv/soft-interface.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/net/batman-adv/soft-interface.c b/net/batman-adv/soft-interface.c
index 15c7237..e8a2bd6 100644
--- a/net/batman-adv/soft-interface.c
+++ b/net/batman-adv/soft-interface.c
@@ -137,6 +137,18 @@ static int batadv_interface_change_mtu(struct net_device *dev, int new_mtu)
return 0;
}
+/**
+ * batadv_interface_set_rx_mode - set the rx mode of a device
+ * @dev: registered network device to modify
+ *
+ * We do not actually need to set any rx filters for the virtual batman
+ * soft interface. However a dummy handler enables a user to set static
+ * multicast listeners for instance.
+ */
+static void batadv_interface_set_rx_mode(struct net_device *dev)
+{
+}
+
static int batadv_interface_tx(struct sk_buff *skb,
struct net_device *soft_iface)
{
@@ -583,6 +595,7 @@ static const struct net_device_ops batadv_netdev_ops = {
.ndo_get_stats = batadv_interface_stats,
.ndo_set_mac_address = batadv_interface_set_mac_addr,
.ndo_change_mtu = batadv_interface_change_mtu,
+ .ndo_set_rx_mode = batadv_interface_set_rx_mode,
.ndo_start_xmit = batadv_interface_tx,
.ndo_validate_addr = eth_validate_addr,
.ndo_add_slave = batadv_softif_slave_add,
--
1.8.3.2
^ permalink raw reply related
* [PATCH 10/16] batman-adv: use htons when possible
From: Antonio Quartulli @ 2013-10-13 11:22 UTC (permalink / raw)
To: davem; +Cc: netdev, b.a.t.m.a.n, Antonio Quartulli, Marek Lindner
In-Reply-To: <1381663381-626-1-git-send-email-antonio@meshcoding.com>
From: Antonio Quartulli <ordex@autistici.org>
When comparing a network ordered value with a constant, it
is better to convert the constant at compile time by means
of htons() instead of converting the value at runtime using
ntohs().
This refactoring may slightly improve the code performance.
Moreover substitute __constant_htons() with htons() since
the latter increase readability and it is smart enough to be
as efficient as the former
Signed-off-by: Antonio Quartulli <ordex@autistici.org>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
Acked-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
---
net/batman-adv/bridge_loop_avoidance.c | 12 ++++++------
net/batman-adv/gateway_client.c | 4 ++--
net/batman-adv/hard-interface.c | 2 +-
net/batman-adv/send.c | 4 ++--
net/batman-adv/soft-interface.c | 4 ++--
5 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/net/batman-adv/bridge_loop_avoidance.c b/net/batman-adv/bridge_loop_avoidance.c
index 70da18a..5bb58d7 100644
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -863,25 +863,25 @@ static int batadv_bla_process_claim(struct batadv_priv *bat_priv,
struct arphdr *arphdr;
uint8_t *hw_src, *hw_dst;
struct batadv_bla_claim_dst *bla_dst;
- uint16_t proto;
+ __be16 proto;
int headlen;
unsigned short vid = BATADV_NO_FLAGS;
int ret;
ethhdr = eth_hdr(skb);
- if (ntohs(ethhdr->h_proto) == ETH_P_8021Q) {
+ if (ethhdr->h_proto == htons(ETH_P_8021Q)) {
vhdr = (struct vlan_ethhdr *)ethhdr;
vid = ntohs(vhdr->h_vlan_TCI) & VLAN_VID_MASK;
vid |= BATADV_VLAN_HAS_TAG;
- proto = ntohs(vhdr->h_vlan_encapsulated_proto);
+ proto = vhdr->h_vlan_encapsulated_proto;
headlen = sizeof(*vhdr);
} else {
- proto = ntohs(ethhdr->h_proto);
+ proto = ethhdr->h_proto;
headlen = ETH_HLEN;
}
- if (proto != ETH_P_ARP)
+ if (proto != htons(ETH_P_ARP))
return 0; /* not a claim frame */
/* this must be a ARP frame. check if it is a claim. */
@@ -1379,7 +1379,7 @@ int batadv_bla_is_backbone_gw(struct sk_buff *skb,
ethhdr = (struct ethhdr *)(((uint8_t *)skb->data) + hdr_size);
- if (ntohs(ethhdr->h_proto) == ETH_P_8021Q) {
+ if (ethhdr->h_proto == htons(ETH_P_8021Q)) {
if (!pskb_may_pull(skb, hdr_size + VLAN_ETH_HLEN))
return 0;
diff --git a/net/batman-adv/gateway_client.c b/net/batman-adv/gateway_client.c
index ac97ca7..053bb31 100644
--- a/net/batman-adv/gateway_client.c
+++ b/net/batman-adv/gateway_client.c
@@ -716,11 +716,11 @@ bool batadv_gw_is_dhcp_target(struct sk_buff *skb, unsigned int *header_len)
/* check for bootp port */
if ((proto == htons(ETH_P_IP)) &&
- (ntohs(udphdr->dest) != 67))
+ (udphdr->dest != htons(67)))
return false;
if ((proto == htons(ETH_P_IPV6)) &&
- (ntohs(udphdr->dest) != 547))
+ (udphdr->dest != htons(547)))
return false;
return true;
diff --git a/net/batman-adv/hard-interface.c b/net/batman-adv/hard-interface.c
index 0c8602e..004017c 100644
--- a/net/batman-adv/hard-interface.c
+++ b/net/batman-adv/hard-interface.c
@@ -379,7 +379,7 @@ int batadv_hardif_enable_interface(struct batadv_hard_iface *hard_iface,
{
struct batadv_priv *bat_priv;
struct net_device *soft_iface, *master;
- __be16 ethertype = __constant_htons(ETH_P_BATMAN);
+ __be16 ethertype = htons(ETH_P_BATMAN);
int ret;
if (hard_iface->if_status != BATADV_IF_NOT_IN_USE)
diff --git a/net/batman-adv/send.c b/net/batman-adv/send.c
index 1a1aa59..4bbcf51 100644
--- a/net/batman-adv/send.c
+++ b/net/batman-adv/send.c
@@ -63,10 +63,10 @@ int batadv_send_skb_packet(struct sk_buff *skb,
ethhdr = eth_hdr(skb);
memcpy(ethhdr->h_source, hard_iface->net_dev->dev_addr, ETH_ALEN);
memcpy(ethhdr->h_dest, dst_addr, ETH_ALEN);
- ethhdr->h_proto = __constant_htons(ETH_P_BATMAN);
+ ethhdr->h_proto = htons(ETH_P_BATMAN);
skb_set_network_header(skb, ETH_HLEN);
- skb->protocol = __constant_htons(ETH_P_BATMAN);
+ skb->protocol = htons(ETH_P_BATMAN);
skb->dev = hard_iface->net_dev;
diff --git a/net/batman-adv/soft-interface.c b/net/batman-adv/soft-interface.c
index 18b1fd9..87e7e4e 100644
--- a/net/batman-adv/soft-interface.c
+++ b/net/batman-adv/soft-interface.c
@@ -145,7 +145,7 @@ static int batadv_interface_tx(struct sk_buff *skb,
struct batadv_hard_iface *primary_if = NULL;
struct batadv_bcast_packet *bcast_packet;
struct vlan_ethhdr *vhdr;
- __be16 ethertype = __constant_htons(ETH_P_BATMAN);
+ __be16 ethertype = htons(ETH_P_BATMAN);
static const uint8_t stp_addr[ETH_ALEN] = {0x01, 0x80, 0xC2, 0x00,
0x00, 0x00};
static const uint8_t ectp_addr[ETH_ALEN] = {0xCF, 0x00, 0x00, 0x00,
@@ -312,7 +312,7 @@ void batadv_interface_rx(struct net_device *soft_iface,
struct vlan_ethhdr *vhdr;
struct batadv_header *batadv_header = (struct batadv_header *)skb->data;
unsigned short vid __maybe_unused = BATADV_NO_FLAGS;
- __be16 ethertype = __constant_htons(ETH_P_BATMAN);
+ __be16 ethertype = htons(ETH_P_BATMAN);
bool is_bcast;
is_bcast = (batadv_header->packet_type == BATADV_BCAST);
--
1.8.3.2
^ permalink raw reply related
* [PATCH 14/16] batman-adv: implement batadv_tt_entries
From: Antonio Quartulli @ 2013-10-13 11:22 UTC (permalink / raw)
To: davem; +Cc: netdev, b.a.t.m.a.n, Antonio Quartulli, Marek Lindner
In-Reply-To: <1381663381-626-1-git-send-email-antonio@meshcoding.com>
From: Antonio Quartulli <antonio@open-mesh.com>
Implement batadv_tt_entries() to get the number of entries
fitting in a given amount of bytes. This computation is done
several times in the code and therefore it is useful to have
an helper function.
Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
---
net/batman-adv/translation-table.c | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/net/batman-adv/translation-table.c b/net/batman-adv/translation-table.c
index 34fa6cc..58636a7 100644
--- a/net/batman-adv/translation-table.c
+++ b/net/batman-adv/translation-table.c
@@ -232,6 +232,17 @@ static int batadv_tt_len(int changes_num)
return changes_num * sizeof(struct batadv_tvlv_tt_change);
}
+/**
+ * batadv_tt_entries - compute the number of entries fitting in tt_len bytes
+ * @tt_len: available space
+ *
+ * Returns the number of entries.
+ */
+static uint16_t batadv_tt_entries(uint16_t tt_len)
+{
+ return tt_len / batadv_tt_len(1);
+}
+
static int batadv_tt_local_init(struct batadv_priv *bat_priv)
{
if (bat_priv->tt.local_hash)
@@ -406,7 +417,7 @@ static void batadv_tt_tvlv_container_update(struct batadv_priv *bat_priv)
if (tt_diff_len == 0)
goto container_register;
- tt_diff_entries_num = tt_diff_len / batadv_tt_len(1);
+ tt_diff_entries_num = batadv_tt_entries(tt_diff_len);
spin_lock_bh(&bat_priv->tt.changes_list_lock);
atomic_set(&bat_priv->tt.local_changes, 0);
@@ -1616,7 +1627,7 @@ batadv_tt_tvlv_generate(struct batadv_priv *bat_priv,
tt_len -= tt_len % sizeof(struct batadv_tvlv_tt_change);
}
- tt_tot = tt_len / sizeof(struct batadv_tvlv_tt_change);
+ tt_tot = batadv_tt_entries(tt_len);
tvlv_tt_data = kzalloc(sizeof(*tvlv_tt_data) + tt_len,
GFP_ATOMIC);
@@ -2567,7 +2578,7 @@ static void batadv_tt_tvlv_ogm_handler_v1(struct batadv_priv *bat_priv,
tt_data = (struct batadv_tvlv_tt_data *)tvlv_value;
tvlv_value_len -= sizeof(*tt_data);
- num_entries = tvlv_value_len / batadv_tt_len(1);
+ num_entries = batadv_tt_entries(tvlv_value_len);
batadv_tt_update_orig(bat_priv, orig,
(unsigned char *)(tt_data + 1),
@@ -2602,7 +2613,7 @@ static int batadv_tt_tvlv_unicast_handler_v1(struct batadv_priv *bat_priv,
tt_data = (struct batadv_tvlv_tt_data *)tvlv_value;
tvlv_value_len -= sizeof(*tt_data);
- num_entries = tvlv_value_len / batadv_tt_len(1);
+ num_entries = batadv_tt_entries(tvlv_value_len);
switch (tt_data->flags & BATADV_TT_DATA_TYPE_MASK) {
case BATADV_TT_REQUEST:
--
1.8.3.2
^ permalink raw reply related
* [PATCH 13/16] batman-adv: remove useless find_router look up
From: Antonio Quartulli @ 2013-10-13 11:22 UTC (permalink / raw)
To: davem
Cc: netdev, b.a.t.m.a.n, Simon Wunderlich, Marek Lindner,
Antonio Quartulli
In-Reply-To: <1381663381-626-1-git-send-email-antonio@meshcoding.com>
From: Simon Wunderlich <simon@open-mesh.com>
This is not used anymore with the new fragmentation, and it might
actually mess up the bonding code because find_router() assumes it
is only called once per packet.
Signed-off-by: Simon Wunderlich <simon@open-mesh.com>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
---
net/batman-adv/send.c | 29 ++++++++---------------------
1 file changed, 8 insertions(+), 21 deletions(-)
diff --git a/net/batman-adv/send.c b/net/batman-adv/send.c
index 4bbcf51..82588e4 100644
--- a/net/batman-adv/send.c
+++ b/net/batman-adv/send.c
@@ -250,30 +250,19 @@ int batadv_send_skb_generic_unicast(struct batadv_priv *bat_priv,
struct ethhdr *ethhdr = (struct ethhdr *)skb->data;
struct batadv_unicast_packet *unicast_packet;
struct batadv_orig_node *orig_node;
- struct batadv_neigh_node *neigh_node;
int ret = NET_RX_DROP;
/* get routing information */
- if (is_multicast_ether_addr(ethhdr->h_dest)) {
+ if (is_multicast_ether_addr(ethhdr->h_dest))
orig_node = batadv_gw_get_selected_orig(bat_priv);
- if (orig_node)
- goto find_router;
- }
+ else
+ /* check for tt host - increases orig_node refcount.
+ * returns NULL in case of AP isolation
+ */
+ orig_node = batadv_transtable_search(bat_priv, ethhdr->h_source,
+ ethhdr->h_dest);
- /* check for tt host - increases orig_node refcount.
- * returns NULL in case of AP isolation
- */
- orig_node = batadv_transtable_search(bat_priv, ethhdr->h_source,
- ethhdr->h_dest);
-
-find_router:
- /* find_router():
- * - if orig_node is NULL it returns NULL
- * - increases neigh_nodes refcount if found.
- */
- neigh_node = batadv_find_router(bat_priv, orig_node, NULL);
-
- if (!neigh_node)
+ if (!orig_node)
goto out;
switch (packet_type) {
@@ -305,8 +294,6 @@ find_router:
ret = 0;
out:
- if (neigh_node)
- batadv_neigh_node_free_ref(neigh_node);
if (orig_node)
batadv_orig_node_free_ref(orig_node);
if (ret == NET_RX_DROP)
--
1.8.3.2
^ permalink raw reply related
* [PATCH v2 net-next] fib_trie: remove duplicated rcu lock
From: baker.kernel @ 2013-10-13 11:50 UTC (permalink / raw)
To: davem, eric.dumazet
Cc: kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel,
baker.zhang
In-Reply-To: <1381636737.3392.29.camel@edumazet-glaptop.roam.corp.google.com>
From: "baker.zhang" <baker.kernel@gmail.com>
fib_table_lookup has included the rcu lock protection.
Signed-off-by: baker.zhang <baker.kernel@gmail.com>
---
Thanks for Eric Dumazet's review.
The V1 patch remove a necessary rcu read lock.
net/ipv4/fib_frontend.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index b3f627a..d846304 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -933,7 +933,6 @@ static void nl_fib_lookup(struct fib_result_nl *frn, struct fib_table *tb)
local_bh_disable();
frn->tb_id = tb->tb_id;
- rcu_read_lock();
frn->err = fib_table_lookup(tb, &fl4, &res, FIB_LOOKUP_NOREF);
if (!frn->err) {
@@ -942,7 +941,6 @@ static void nl_fib_lookup(struct fib_result_nl *frn, struct fib_table *tb)
frn->type = res.type;
frn->scope = res.scope;
}
- rcu_read_unlock();
local_bh_enable();
}
}
--
1.8.1.2
^ permalink raw reply related
* [PATCH 11/16] batman-adv: create common header for ICMP packets
From: Antonio Quartulli @ 2013-10-13 11:22 UTC (permalink / raw)
To: davem; +Cc: netdev, b.a.t.m.a.n, Antonio Quartulli, Marek Lindner
In-Reply-To: <1381663381-626-1-git-send-email-antonio@meshcoding.com>
From: Antonio Quartulli <antonio@open-mesh.com>
the icmp and the icmp_rr packets share the same initial
fields since they use the same code to be processed and
forwarded.
Extract the common fields and put them into a separate
struct so that future ICMP packets can be easily added
without bloating the packet definition.
However, keep the seqno field outside of the newly created
common header because future ICMP types may require a
bigger sequence number space.
This change breaks compatibility due to fields reordering
in the ICMP headers.
Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
---
net/batman-adv/icmp_socket.c | 22 ++++++++++-----------
net/batman-adv/main.c | 4 ++--
net/batman-adv/packet.h | 46 ++++++++++++++++++++++++++++++--------------
net/batman-adv/routing.c | 40 ++++++++++++++++++++------------------
4 files changed, 66 insertions(+), 46 deletions(-)
diff --git a/net/batman-adv/icmp_socket.c b/net/batman-adv/icmp_socket.c
index 5a99bb4..82ac647 100644
--- a/net/batman-adv/icmp_socket.c
+++ b/net/batman-adv/icmp_socket.c
@@ -192,25 +192,25 @@ static ssize_t batadv_socket_write(struct file *file, const char __user *buff,
goto free_skb;
}
- if (icmp_packet->header.packet_type != BATADV_ICMP) {
+ if (icmp_packet->icmph.header.packet_type != BATADV_ICMP) {
batadv_dbg(BATADV_DBG_BATMAN, bat_priv,
"Error - can't send packet from char device: got bogus packet type (expected: BAT_ICMP)\n");
len = -EINVAL;
goto free_skb;
}
- if (icmp_packet->msg_type != BATADV_ECHO_REQUEST) {
+ if (icmp_packet->icmph.msg_type != BATADV_ECHO_REQUEST) {
batadv_dbg(BATADV_DBG_BATMAN, bat_priv,
"Error - can't send packet from char device: got bogus message type (expected: ECHO_REQUEST)\n");
len = -EINVAL;
goto free_skb;
}
- icmp_packet->uid = socket_client->index;
+ icmp_packet->icmph.uid = socket_client->index;
- if (icmp_packet->header.version != BATADV_COMPAT_VERSION) {
- icmp_packet->msg_type = BATADV_PARAMETER_PROBLEM;
- icmp_packet->header.version = BATADV_COMPAT_VERSION;
+ if (icmp_packet->icmph.header.version != BATADV_COMPAT_VERSION) {
+ icmp_packet->icmph.msg_type = BATADV_PARAMETER_PROBLEM;
+ icmp_packet->icmph.header.version = BATADV_COMPAT_VERSION;
batadv_socket_add_packet(socket_client, icmp_packet,
packet_len);
goto free_skb;
@@ -219,7 +219,7 @@ static ssize_t batadv_socket_write(struct file *file, const char __user *buff,
if (atomic_read(&bat_priv->mesh_state) != BATADV_MESH_ACTIVE)
goto dst_unreach;
- orig_node = batadv_orig_hash_find(bat_priv, icmp_packet->dst);
+ orig_node = batadv_orig_hash_find(bat_priv, icmp_packet->icmph.dst);
if (!orig_node)
goto dst_unreach;
@@ -233,7 +233,7 @@ static ssize_t batadv_socket_write(struct file *file, const char __user *buff,
if (neigh_node->if_incoming->if_status != BATADV_IF_ACTIVE)
goto dst_unreach;
- memcpy(icmp_packet->orig,
+ memcpy(icmp_packet->icmph.orig,
primary_if->net_dev->dev_addr, ETH_ALEN);
if (packet_len == sizeof(struct batadv_icmp_packet_rr))
@@ -244,7 +244,7 @@ static ssize_t batadv_socket_write(struct file *file, const char __user *buff,
goto out;
dst_unreach:
- icmp_packet->msg_type = BATADV_DESTINATION_UNREACHABLE;
+ icmp_packet->icmph.msg_type = BATADV_DESTINATION_UNREACHABLE;
batadv_socket_add_packet(socket_client, icmp_packet, packet_len);
free_skb:
kfree_skb(skb);
@@ -318,7 +318,7 @@ static void batadv_socket_add_packet(struct batadv_socket_client *socket_client,
/* while waiting for the lock the socket_client could have been
* deleted
*/
- if (!batadv_socket_client_hash[icmp_packet->uid]) {
+ if (!batadv_socket_client_hash[icmp_packet->icmph.uid]) {
spin_unlock_bh(&socket_client->lock);
kfree(socket_packet);
return;
@@ -347,7 +347,7 @@ void batadv_socket_receive_packet(struct batadv_icmp_packet_rr *icmp_packet,
{
struct batadv_socket_client *hash;
- hash = batadv_socket_client_hash[icmp_packet->uid];
+ hash = batadv_socket_client_hash[icmp_packet->icmph.uid];
if (hash)
batadv_socket_add_packet(hash, icmp_packet, icmp_len);
}
diff --git a/net/batman-adv/main.c b/net/batman-adv/main.c
index ca6f134..519138e 100644
--- a/net/batman-adv/main.c
+++ b/net/batman-adv/main.c
@@ -401,8 +401,8 @@ static void batadv_recv_handler_init(void)
BUILD_BUG_ON(offsetof(struct batadv_unicast_packet, dest) != 4);
BUILD_BUG_ON(offsetof(struct batadv_unicast_tvlv_packet, dst) != 4);
BUILD_BUG_ON(offsetof(struct batadv_frag_packet, dest) != 4);
- BUILD_BUG_ON(offsetof(struct batadv_icmp_packet, dst) != 4);
- BUILD_BUG_ON(offsetof(struct batadv_icmp_packet_rr, dst) != 4);
+ BUILD_BUG_ON(offsetof(struct batadv_icmp_packet, icmph.dst) != 4);
+ BUILD_BUG_ON(offsetof(struct batadv_icmp_packet_rr, icmph.dst) != 4);
/* broadcast packet */
batadv_rx_handler[BATADV_BCAST] = batadv_recv_bcast_packet;
diff --git a/net/batman-adv/packet.h b/net/batman-adv/packet.h
index aa46c27..65e723e 100644
--- a/net/batman-adv/packet.h
+++ b/net/batman-adv/packet.h
@@ -186,29 +186,47 @@ struct batadv_ogm_packet {
#define BATADV_OGM_HLEN sizeof(struct batadv_ogm_packet)
+/**
+ * batadv_icmp_header - common ICMP header
+ * @header: common batman header
+ * @msg_type: ICMP packet type
+ * @dst: address of the destination node
+ * @orig: address of the source node
+ * @uid: local ICMP socket identifier
+ */
+struct batadv_icmp_header {
+ struct batadv_header header;
+ uint8_t msg_type; /* see ICMP message types above */
+ uint8_t dst[ETH_ALEN];
+ uint8_t orig[ETH_ALEN];
+ uint8_t uid;
+};
+
+/**
+ * batadv_icmp_packet - ICMP packet
+ * @icmph: common ICMP header
+ * @reserved: not used - useful for alignment
+ * @seqno: ICMP sequence number
+ */
struct batadv_icmp_packet {
- struct batadv_header header;
- uint8_t msg_type; /* see ICMP message types above */
- uint8_t dst[ETH_ALEN];
- uint8_t orig[ETH_ALEN];
- __be16 seqno;
- uint8_t uid;
+ struct batadv_icmp_header icmph;
uint8_t reserved;
+ __be16 seqno;
};
#define BATADV_RR_LEN 16
-/* icmp_packet_rr must start with all fields from imcp_packet
- * as this is assumed by code that handles ICMP packets
+/**
+ * batadv_icmp_packet_rr - ICMP RouteRecord packet
+ * @icmph: common ICMP header
+ * @rr_cur: number of entries the rr array
+ * @seqno: ICMP sequence number
+ * @rr: route record array
*/
struct batadv_icmp_packet_rr {
- struct batadv_header header;
- uint8_t msg_type; /* see ICMP message types above */
- uint8_t dst[ETH_ALEN];
- uint8_t orig[ETH_ALEN];
- __be16 seqno;
- uint8_t uid;
+ struct batadv_icmp_header icmph;
uint8_t rr_cur;
+ __be16 seqno;
uint8_t rr[BATADV_RR_LEN][ETH_ALEN];
};
diff --git a/net/batman-adv/routing.c b/net/batman-adv/routing.c
index a080f63..3281a50 100644
--- a/net/batman-adv/routing.c
+++ b/net/batman-adv/routing.c
@@ -258,7 +258,7 @@ static int batadv_recv_my_icmp_packet(struct batadv_priv *bat_priv,
icmp_packet = (struct batadv_icmp_packet_rr *)skb->data;
/* add data to device queue */
- if (icmp_packet->msg_type != BATADV_ECHO_REQUEST) {
+ if (icmp_packet->icmph.msg_type != BATADV_ECHO_REQUEST) {
batadv_socket_receive_packet(icmp_packet, icmp_len);
goto out;
}
@@ -269,7 +269,7 @@ static int batadv_recv_my_icmp_packet(struct batadv_priv *bat_priv,
/* answer echo request (ping) */
/* get routing information */
- orig_node = batadv_orig_hash_find(bat_priv, icmp_packet->orig);
+ orig_node = batadv_orig_hash_find(bat_priv, icmp_packet->icmph.orig);
if (!orig_node)
goto out;
@@ -279,10 +279,11 @@ static int batadv_recv_my_icmp_packet(struct batadv_priv *bat_priv,
icmp_packet = (struct batadv_icmp_packet_rr *)skb->data;
- memcpy(icmp_packet->dst, icmp_packet->orig, ETH_ALEN);
- memcpy(icmp_packet->orig, primary_if->net_dev->dev_addr, ETH_ALEN);
- icmp_packet->msg_type = BATADV_ECHO_REPLY;
- icmp_packet->header.ttl = BATADV_TTL;
+ memcpy(icmp_packet->icmph.dst, icmp_packet->icmph.orig, ETH_ALEN);
+ memcpy(icmp_packet->icmph.orig, primary_if->net_dev->dev_addr,
+ ETH_ALEN);
+ icmp_packet->icmph.msg_type = BATADV_ECHO_REPLY;
+ icmp_packet->icmph.header.ttl = BATADV_TTL;
if (batadv_send_skb_to_orig(skb, orig_node, NULL) != NET_XMIT_DROP)
ret = NET_RX_SUCCESS;
@@ -306,9 +307,9 @@ static int batadv_recv_icmp_ttl_exceeded(struct batadv_priv *bat_priv,
icmp_packet = (struct batadv_icmp_packet *)skb->data;
/* send TTL exceeded if packet is an echo request (traceroute) */
- if (icmp_packet->msg_type != BATADV_ECHO_REQUEST) {
+ if (icmp_packet->icmph.msg_type != BATADV_ECHO_REQUEST) {
pr_debug("Warning - can't forward icmp packet from %pM to %pM: ttl exceeded\n",
- icmp_packet->orig, icmp_packet->dst);
+ icmp_packet->icmph.orig, icmp_packet->icmph.dst);
goto out;
}
@@ -317,7 +318,7 @@ static int batadv_recv_icmp_ttl_exceeded(struct batadv_priv *bat_priv,
goto out;
/* get routing information */
- orig_node = batadv_orig_hash_find(bat_priv, icmp_packet->orig);
+ orig_node = batadv_orig_hash_find(bat_priv, icmp_packet->icmph.orig);
if (!orig_node)
goto out;
@@ -327,10 +328,11 @@ static int batadv_recv_icmp_ttl_exceeded(struct batadv_priv *bat_priv,
icmp_packet = (struct batadv_icmp_packet *)skb->data;
- memcpy(icmp_packet->dst, icmp_packet->orig, ETH_ALEN);
- memcpy(icmp_packet->orig, primary_if->net_dev->dev_addr, ETH_ALEN);
- icmp_packet->msg_type = BATADV_TTL_EXCEEDED;
- icmp_packet->header.ttl = BATADV_TTL;
+ memcpy(icmp_packet->icmph.dst, icmp_packet->icmph.orig, ETH_ALEN);
+ memcpy(icmp_packet->icmph.orig, primary_if->net_dev->dev_addr,
+ ETH_ALEN);
+ icmp_packet->icmph.msg_type = BATADV_TTL_EXCEEDED;
+ icmp_packet->icmph.header.ttl = BATADV_TTL;
if (batadv_send_skb_to_orig(skb, orig_node, NULL) != NET_XMIT_DROP)
ret = NET_RX_SUCCESS;
@@ -379,8 +381,8 @@ int batadv_recv_icmp_packet(struct sk_buff *skb,
icmp_packet = (struct batadv_icmp_packet_rr *)skb->data;
/* add record route information if not full */
- if ((icmp_packet->msg_type == BATADV_ECHO_REPLY ||
- icmp_packet->msg_type == BATADV_ECHO_REQUEST) &&
+ if ((icmp_packet->icmph.msg_type == BATADV_ECHO_REPLY ||
+ icmp_packet->icmph.msg_type == BATADV_ECHO_REQUEST) &&
(hdr_size == sizeof(struct batadv_icmp_packet_rr)) &&
(icmp_packet->rr_cur < BATADV_RR_LEN)) {
memcpy(&(icmp_packet->rr[icmp_packet->rr_cur]),
@@ -389,15 +391,15 @@ int batadv_recv_icmp_packet(struct sk_buff *skb,
}
/* packet for me */
- if (batadv_is_my_mac(bat_priv, icmp_packet->dst))
+ if (batadv_is_my_mac(bat_priv, icmp_packet->icmph.dst))
return batadv_recv_my_icmp_packet(bat_priv, skb, hdr_size);
/* TTL exceeded */
- if (icmp_packet->header.ttl < 2)
+ if (icmp_packet->icmph.header.ttl < 2)
return batadv_recv_icmp_ttl_exceeded(bat_priv, skb);
/* get routing information */
- orig_node = batadv_orig_hash_find(bat_priv, icmp_packet->dst);
+ orig_node = batadv_orig_hash_find(bat_priv, icmp_packet->icmph.dst);
if (!orig_node)
goto out;
@@ -408,7 +410,7 @@ int batadv_recv_icmp_packet(struct sk_buff *skb,
icmp_packet = (struct batadv_icmp_packet_rr *)skb->data;
/* decrement ttl */
- icmp_packet->header.ttl--;
+ icmp_packet->icmph.header.ttl--;
/* route it */
if (batadv_send_skb_to_orig(skb, orig_node, recv_if) != NET_XMIT_DROP)
--
1.8.3.2
^ permalink raw reply related
* [PATCH 12/16] batman-adv: consider network coding overhead when calculating required mtu
From: Antonio Quartulli @ 2013-10-13 11:22 UTC (permalink / raw)
To: davem; +Cc: netdev, b.a.t.m.a.n, Marek Lindner, Antonio Quartulli
In-Reply-To: <1381663381-626-1-git-send-email-antonio@meshcoding.com>
From: Marek Lindner <lindner_marek@yahoo.de>
The module prints a warning when the MTU on the hard interface is too
small to transfer payload traffic without fragmentation. The required
MTU is calculated based on the encapsulation header size. If network
coding is compild into the module its header size is taken into
account as well.
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
---
net/batman-adv/hard-interface.c | 19 ++++++++++---------
net/batman-adv/main.c | 25 +++++++++++++++++++++++++
net/batman-adv/main.h | 1 +
net/batman-adv/soft-interface.c | 2 +-
net/batman-adv/types.h | 7 -------
5 files changed, 37 insertions(+), 17 deletions(-)
diff --git a/net/batman-adv/hard-interface.c b/net/batman-adv/hard-interface.c
index 004017c..d564af2 100644
--- a/net/batman-adv/hard-interface.c
+++ b/net/batman-adv/hard-interface.c
@@ -269,9 +269,10 @@ int batadv_hardif_min_mtu(struct net_device *soft_iface)
const struct batadv_priv *bat_priv = netdev_priv(soft_iface);
const struct batadv_hard_iface *hard_iface;
/* allow big frames if all devices are capable to do so
- * (have MTU > 1500 + BAT_HEADER_LEN)
+ * (have MTU > 1500 + batadv_max_header_len())
*/
int min_mtu = ETH_DATA_LEN;
+ int max_header_len = batadv_max_header_len();
if (atomic_read(&bat_priv->fragmentation))
goto out;
@@ -285,8 +286,7 @@ int batadv_hardif_min_mtu(struct net_device *soft_iface)
if (hard_iface->soft_iface != soft_iface)
continue;
- min_mtu = min_t(int,
- hard_iface->net_dev->mtu - BATADV_HEADER_LEN,
+ min_mtu = min_t(int, hard_iface->net_dev->mtu - max_header_len,
min_mtu);
}
rcu_read_unlock();
@@ -380,6 +380,7 @@ int batadv_hardif_enable_interface(struct batadv_hard_iface *hard_iface,
struct batadv_priv *bat_priv;
struct net_device *soft_iface, *master;
__be16 ethertype = htons(ETH_P_BATMAN);
+ int max_header_len = batadv_max_header_len();
int ret;
if (hard_iface->if_status != BATADV_IF_NOT_IN_USE)
@@ -448,18 +449,18 @@ int batadv_hardif_enable_interface(struct batadv_hard_iface *hard_iface,
hard_iface->net_dev->name);
if (atomic_read(&bat_priv->fragmentation) &&
- hard_iface->net_dev->mtu < ETH_DATA_LEN + BATADV_HEADER_LEN)
+ hard_iface->net_dev->mtu < ETH_DATA_LEN + max_header_len)
batadv_info(hard_iface->soft_iface,
- "The MTU of interface %s is too small (%i) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to %zi would solve the problem.\n",
+ "The MTU of interface %s is too small (%i) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to %i would solve the problem.\n",
hard_iface->net_dev->name, hard_iface->net_dev->mtu,
- ETH_DATA_LEN + BATADV_HEADER_LEN);
+ ETH_DATA_LEN + max_header_len);
if (!atomic_read(&bat_priv->fragmentation) &&
- hard_iface->net_dev->mtu < ETH_DATA_LEN + BATADV_HEADER_LEN)
+ hard_iface->net_dev->mtu < ETH_DATA_LEN + max_header_len)
batadv_info(hard_iface->soft_iface,
- "The MTU of interface %s is too small (%i) to handle the transport of batman-adv packets. If you experience problems getting traffic through try increasing the MTU to %zi.\n",
+ "The MTU of interface %s is too small (%i) to handle the transport of batman-adv packets. If you experience problems getting traffic through try increasing the MTU to %i.\n",
hard_iface->net_dev->name, hard_iface->net_dev->mtu,
- ETH_DATA_LEN + BATADV_HEADER_LEN);
+ ETH_DATA_LEN + max_header_len);
if (batadv_hardif_is_iface_up(hard_iface))
batadv_hardif_activate_interface(hard_iface);
diff --git a/net/batman-adv/main.c b/net/batman-adv/main.c
index 519138e..7f3a5c4 100644
--- a/net/batman-adv/main.c
+++ b/net/batman-adv/main.c
@@ -256,6 +256,31 @@ out:
}
/**
+ * batadv_max_header_len - calculate maximum encapsulation overhead for a
+ * payload packet
+ *
+ * Return the maximum encapsulation overhead in bytes.
+ */
+int batadv_max_header_len(void)
+{
+ int header_len = 0;
+
+ header_len = max_t(int, header_len,
+ sizeof(struct batadv_unicast_packet));
+ header_len = max_t(int, header_len,
+ sizeof(struct batadv_unicast_4addr_packet));
+ header_len = max_t(int, header_len,
+ sizeof(struct batadv_bcast_packet));
+
+#ifdef CONFIG_BATMAN_ADV_NC
+ header_len = max_t(int, header_len,
+ sizeof(struct batadv_coded_packet));
+#endif
+
+ return header_len;
+}
+
+/**
* batadv_skb_set_priority - sets skb priority according to packet content
* @skb: the packet to be sent
* @offset: offset to the packet content
diff --git a/net/batman-adv/main.h b/net/batman-adv/main.h
index 6a74a42..54c13d5 100644
--- a/net/batman-adv/main.h
+++ b/net/batman-adv/main.h
@@ -191,6 +191,7 @@ void batadv_mesh_free(struct net_device *soft_iface);
int batadv_is_my_mac(struct batadv_priv *bat_priv, const uint8_t *addr);
struct batadv_hard_iface *
batadv_seq_print_text_primary_if_get(struct seq_file *seq);
+int batadv_max_header_len(void);
void batadv_skb_set_priority(struct sk_buff *skb, int offset);
int batadv_batman_skb_recv(struct sk_buff *skb, struct net_device *dev,
struct packet_type *ptype,
diff --git a/net/batman-adv/soft-interface.c b/net/batman-adv/soft-interface.c
index 87e7e4e..15c7237 100644
--- a/net/batman-adv/soft-interface.c
+++ b/net/batman-adv/soft-interface.c
@@ -626,7 +626,7 @@ static void batadv_softif_init_early(struct net_device *dev)
*/
dev->mtu = ETH_DATA_LEN;
/* reserve more space in the skbuff for our header */
- dev->hard_header_len = BATADV_HEADER_LEN;
+ dev->hard_header_len = batadv_max_header_len();
/* generate random address */
eth_hw_addr_random(dev);
diff --git a/net/batman-adv/types.h b/net/batman-adv/types.h
index d517d5d..5cbb0d0 100644
--- a/net/batman-adv/types.h
+++ b/net/batman-adv/types.h
@@ -24,13 +24,6 @@
#include "bitarray.h"
#include <linux/kernel.h>
-/**
- * Maximum overhead for the encapsulation for a payload packet
- */
-#define BATADV_HEADER_LEN \
- (ETH_HLEN + max(sizeof(struct batadv_unicast_packet), \
- sizeof(struct batadv_bcast_packet)))
-
#ifdef CONFIG_BATMAN_ADV_DAT
/* batadv_dat_addr_t is the type used for all DHT addresses. If it is changed,
--
1.8.3.2
^ 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