* Re: [PATCH net-next v2 1/2] net: Add skb_get_hash_noeval
From: Eric Dumazet @ 2014-01-15 0:20 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <alpine.DEB.2.02.1401141556350.25158@tomh.mtv.corp.google.com>
On Tue, 2014-01-14 at 16:01 -0800, Tom Herbert wrote:
> Function to just return skb->rxhash without checking to see if it needs
> to be recomputed.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
> include/linux/skbuff.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index d97f2d0..bbdc847 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -771,6 +771,11 @@ static inline __u32 skb_get_hash(struct sk_buff *skb)
> return skb->rxhash;
> }
>
> +static inline __u32 skb_get_hash_noeval(struct sk_buff *skb)
const struct sk_buff *skb
> +{
> + return skb->rxhash;
> +}
> +
> static inline void skb_clear_hash(struct sk_buff *skb)
> {
> skb->rxhash = 0;
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] net: Add skb_get_hash_noeval
From: Cong Wang @ 2014-01-15 0:07 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, netdev
In-Reply-To: <alpine.DEB.2.02.1401141556350.25158@tomh.mtv.corp.google.com>
On Tue, Jan 14, 2014 at 4:01 PM, Tom Herbert <therbert@google.com> wrote:
> Function to just return skb->rxhash without checking to see if it needs
> to be recomputed.
>
skb_get_hash_raw() is a better name.
^ permalink raw reply
* [PATCH net-next v2 2/2] net: Check skb->rxhash in gro_receive
From: Tom Herbert @ 2014-01-15 0:02 UTC (permalink / raw)
To: davem, netdev
When initializing a gro_list for a packet, first check the rxhash of
the incoming skb against that of the skb's in the list. This should be
a very strong inidicator of whether the flow is going to be matched,
and potentially allows a lot of other checks to be short circuited.
Use skb_hash_noeval so that we don't force the hash to be calculated.
Tested by running netperf 200 TCP_STREAMs between two machines with
GRO, HW rxhash, and 1G. Saw no performance degration, slight reduction
of time in dev_gro_receive.
Signed-off-by: Tom Herbert <therbert@google.com>
---
net/core/dev.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index a828015..4232b32 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3794,10 +3794,18 @@ static void gro_list_prepare(struct napi_struct *napi, struct sk_buff *skb)
{
struct sk_buff *p;
unsigned int maclen = skb->dev->hard_header_len;
+ u32 hash = skb_get_hash_noeval(skb);
for (p = napi->gro_list; p; p = p->next) {
unsigned long diffs;
+ NAPI_GRO_CB(p)->flush = 0;
+
+ if (hash != skb_get_hash_noeval(p)) {
+ NAPI_GRO_CB(p)->same_flow = 0;
+ continue;
+ }
+
diffs = (unsigned long)p->dev ^ (unsigned long)skb->dev;
diffs |= p->vlan_tci ^ skb->vlan_tci;
if (maclen == ETH_HLEN)
@@ -3808,7 +3816,6 @@ static void gro_list_prepare(struct napi_struct *napi, struct sk_buff *skb)
skb_gro_mac_header(skb),
maclen);
NAPI_GRO_CB(p)->same_flow = !diffs;
- NAPI_GRO_CB(p)->flush = 0;
}
}
--
1.8.5.2
^ permalink raw reply related
* [PATCH net-next v2 1/2] net: Add skb_get_hash_noeval
From: Tom Herbert @ 2014-01-15 0:01 UTC (permalink / raw)
To: davem, netdev
Function to just return skb->rxhash without checking to see if it needs
to be recomputed.
Signed-off-by: Tom Herbert <therbert@google.com>
---
include/linux/skbuff.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index d97f2d0..bbdc847 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -771,6 +771,11 @@ static inline __u32 skb_get_hash(struct sk_buff *skb)
return skb->rxhash;
}
+static inline __u32 skb_get_hash_noeval(struct sk_buff *skb)
+{
+ return skb->rxhash;
+}
+
static inline void skb_clear_hash(struct sk_buff *skb)
{
skb->rxhash = 0;
--
1.8.5.2
^ permalink raw reply related
* [BUG] eth_type_trans() can access stale data
From: Eric Dumazet @ 2014-01-14 23:52 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Following code :
if (unlikely(skb->len >= 2 && *(unsigned short *)(skb->data) == 0xFFFF))
return htons(ETH_P_802_3);
expects the additional bytes are in skb->head
I do not think all eth_type_trans() are ready for a pskb_may_pull()
(I am too lazy to perform a whole check)
Would following workaround be OK ?
diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c
index 8f032bae60ad..d95403098f09 100644
--- a/net/ethernet/eth.c
+++ b/net/ethernet/eth.c
@@ -194,7 +194,8 @@ __be16 eth_type_trans(struct sk_buff *skb, struct net_device *dev)
* layer. We look for FFFF which isn't a used 802.2 SSAP/DSAP. This
* won't work for fault tolerant netware but does for the rest.
*/
- if (unlikely(skb->len >= 2 && *(unsigned short *)(skb->data) == 0xFFFF))
+ if (unlikely(skb_headlen(skb) >= 2 &&
+ *(unsigned short *)(skb->data) == 0xFFFF))
return htons(ETH_P_802_3);
/*
^ permalink raw reply related
* [PATCH net-next 2/2] net: mvneta: make mvneta_txq_done() return void
From: Arnaud Ebalard @ 2014-01-14 23:46 UTC (permalink / raw)
To: David Miller, Willy Tarreau, Thomas Petazzoni; +Cc: netdev, linux-arm-kernel
In-Reply-To: <cover.1389742334.git.arno@natisbad.org>
The function return parameter is not used in mvneta_tx_done_gbe(),
where the function is called. This patch makes the function return
void.
Signed-off-by: Arnaud Ebalard <arno@natisbad.org>
---
drivers/net/ethernet/marvell/mvneta.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 8c5150124b5e..f418f4f20f94 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -1314,15 +1314,16 @@ static void mvneta_txq_bufs_free(struct mvneta_port *pp,
}
/* Handle end of transmission */
-static int mvneta_txq_done(struct mvneta_port *pp,
+static void mvneta_txq_done(struct mvneta_port *pp,
struct mvneta_tx_queue *txq)
{
struct netdev_queue *nq = netdev_get_tx_queue(pp->dev, txq->id);
int tx_done;
tx_done = mvneta_txq_sent_desc_proc(pp, txq);
- if (tx_done == 0)
- return tx_done;
+ if (!tx_done)
+ return;
+
mvneta_txq_bufs_free(pp, txq, tx_done);
txq->count -= tx_done;
@@ -1331,8 +1332,6 @@ static int mvneta_txq_done(struct mvneta_port *pp,
if (txq->size - txq->count >= MAX_SKB_FRAGS + 1)
netif_tx_wake_queue(nq);
}
-
- return tx_done;
}
static void *mvneta_frag_alloc(const struct mvneta_port *pp)
--
1.8.5.2
^ permalink raw reply related
* [PATCH net-next 1/2] net: mvneta: mvneta_tx_done_gbe() cleanups
From: Arnaud Ebalard @ 2014-01-14 23:45 UTC (permalink / raw)
To: David Miller, Willy Tarreau, Thomas Petazzoni; +Cc: netdev, linux-arm-kernel
In-Reply-To: <cover.1389742334.git.arno@natisbad.org>
mvneta_tx_done_gbe() return value and third parameter are no more
used. This patch changes the function prototype and removes a useless
variable where the function is called.
Signed-off-by: Arnaud Ebalard <arno@natisbad.org>
---
drivers/net/ethernet/marvell/mvneta.c | 17 ++++-------------
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index f5fc7a249880..8c5150124b5e 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -1704,30 +1704,23 @@ static void mvneta_txq_done_force(struct mvneta_port *pp,
/* Handle tx done - called in softirq context. The <cause_tx_done> argument
* must be a valid cause according to MVNETA_TXQ_INTR_MASK_ALL.
*/
-static u32 mvneta_tx_done_gbe(struct mvneta_port *pp, u32 cause_tx_done,
- int *tx_todo)
+static void mvneta_tx_done_gbe(struct mvneta_port *pp, u32 cause_tx_done)
{
struct mvneta_tx_queue *txq;
- u32 tx_done = 0;
struct netdev_queue *nq;
- *tx_todo = 0;
while (cause_tx_done) {
txq = mvneta_tx_done_policy(pp, cause_tx_done);
nq = netdev_get_tx_queue(pp->dev, txq->id);
__netif_tx_lock(nq, smp_processor_id());
- if (txq->count) {
- tx_done += mvneta_txq_done(pp, txq);
- *tx_todo += txq->count;
- }
+ if (txq->count)
+ mvneta_txq_done(pp, txq);
__netif_tx_unlock(nq);
cause_tx_done &= ~((1 << txq->id));
}
-
- return tx_done;
}
/* Compute crc8 of the specified address, using a unique algorithm ,
@@ -1961,9 +1954,7 @@ static int mvneta_poll(struct napi_struct *napi, int budget)
/* Release Tx descriptors */
if (cause_rx_tx & MVNETA_TX_INTR_MASK_ALL) {
- int tx_todo = 0;
-
- mvneta_tx_done_gbe(pp, (cause_rx_tx & MVNETA_TX_INTR_MASK_ALL), &tx_todo);
+ mvneta_tx_done_gbe(pp, (cause_rx_tx & MVNETA_TX_INTR_MASK_ALL));
cause_rx_tx &= ~MVNETA_TX_INTR_MASK_ALL;
}
--
1.8.5.2
^ permalink raw reply related
* [PATCH net-next 0/2] net: mvneta: simple cleanups
From: Arnaud Ebalard @ 2014-01-14 23:45 UTC (permalink / raw)
To: David Miller, Willy Tarreau, Thomas Petazzoni; +Cc: netdev, linux-arm-kernel
Those two patches are intended for net-next. They apply on top of
performance improvements patches from Willy for mvneta driver.
They provide some simple cleanups for unused variables, function
params or return values.
Arnaud Ebalard (2):
net: mvneta: mvneta_tx_done_gbe() cleanups
net: mvneta: make mvneta_txq_done() return void
drivers/net/ethernet/marvell/mvneta.c | 26 ++++++++------------------
1 file changed, 8 insertions(+), 18 deletions(-)
--
1.8.5.2
^ permalink raw reply
* Re: [PATCH] ieee802154: Fix memory leak in ieee802154_add_iface()
From: David Miller @ 2014-01-14 23:41 UTC (permalink / raw)
To: cengelma; +Cc: alex.bluesman.smirnov, dbaryshkov, netdev, linux-zigbee-devel
In-Reply-To: <20140111221930.7255e2be@spike>
From: Christian Engelmayer <cengelma@gmx.at>
Date: Sat, 11 Jan 2014 22:19:30 +0100
> Fix a memory leak in the ieee802154_add_iface() error handling path.
> Detected by Coverity: CID 710490.
>
> Signed-off-by: Christian Engelmayer <cengelma@gmx.at>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] IPv6: add option to use anycast addresses as source addresses in icmp error messages
From: Hannes Frederic Sowa @ 2014-01-14 23:38 UTC (permalink / raw)
To: Francois-Xavier Le Bail, netdev, Bill Fink, David S. Miller,
Alexey Kuznetsov, James Morris, Hideaki Yoshifuji,
Patrick McHardy
In-Reply-To: <20140114131344.GR6586@order.stressinduktion.org>
On Tue, Jan 14, 2014 at 02:13:44PM +0100, Hannes Frederic Sowa wrote:
> On Mon, Jan 13, 2014 at 06:22:44PM +0100, Francois-Xavier Le Bail wrote:
> > - Add "anycast_src_icmp_error" sysctl to control the use of anycast addresses
> > as source addresses for ICMPv6 error messages. This sysctl is false by
> > default to preserve existing behavior.
> > - Use it in icmp6_send().
> >
> > Suggested-by: Bill Fink <billfink@mindspring.com>
> > Signed-off-by: Francois-Xavier Le Bail <fx.lebail@yahoo.com>
>
> Regarding the anycast patches, I contacted someone from IETF.
>
> The number of sysctls needed to get introduced to have all the flexibility
> regarding source address selection and don't break backward compatibility
> concerns me a bit.
>
> Especially on end hosts, where those switches will be important, I think we
> really have to think about sensible defaults without breaking current
> software.
>
> I currently consider a per-address flag, if those anycast addresses
> should be available in source address selection (also with an enhancement to
> current IPV6_JOIN_ANYCAST logic).
Francois, we should really think about this. Also if we should just
make the pre-defined subnet address just a normal anycast address in the
long-term (which just happens to get automatically added to an interface
if forwarding is enabled) and bundle all the source address selection
logic on the per-address state.
If that would be the case, we could revert
509aba3b0d366b7f16a9a2eebac1156b25f5f622 ("IPv6: add the option to use
anycast addresses as source addresses in echo reply") and thus would
eliminate one sysctl.
It would be fine if we can make this decision before David merges with
Linus. I guess we can still do this decision while in -rc phase. But
as soon as the knob is in a released version of linux we can never take
it back (I really don't like sysctls).
Greetings,
Hannes
^ permalink raw reply
* Re: pull-request: can-next 2014-01-11
From: David Miller @ 2014-01-14 23:30 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can, kernel
In-Reply-To: <52D191E2.8040703@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Sat, 11 Jan 2014 19:48:02 +0100
> this is a pull request of three patches for net-next/master.
>
> Oleg Moroz added support for a new PCI card to the generic SJA1000 PCI
> driver, Guenter Roeck's patch limits the flexcan driver to little
> endian arm (and powerpc) and I fixed a sparse warning found by the
> kbuild robot in the ti_hecc driver.
Pulled, thanks Marc.
^ permalink raw reply
* Re: [Xen-devel][PATCH net-next] xen-netfront: clean up code in xennet_release_rx_bufs
From: David Miller @ 2014-01-14 23:28 UTC (permalink / raw)
To: Annie.li; +Cc: xen-devel, netdev, konrad.wilk, ian.campbell, wei.liu2
In-Reply-To: <1389307718-2845-1-git-send-email-Annie.li@oracle.com>
From: Annie Li <Annie.li@oracle.com>
Date: Fri, 10 Jan 2014 06:48:38 +0800
> Current netfront only grants pages for grant copy, not for grant transfer, so
> remove corresponding transfer code and add receiving copy code in
> xennet_release_rx_bufs.
>
> Signed-off-by: Annie Li <Annie.li@oracle.com>
If a Xen networking driver would review this I'd appreciate it.
Thanks.
^ permalink raw reply
* Re: [PATCH RFC] reciprocal_divide: correction/update of the algorithm
From: Borislav Petkov @ 2014-01-14 23:25 UTC (permalink / raw)
To: Eric Dumazet
Cc: Austin S Hemmelgarn, Hannes Frederic Sowa, netdev, dborkman,
linux-kernel, darkjames-ws
In-Reply-To: <1389739537.31367.273.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, Jan 14, 2014 at 02:45:37PM -0800, Eric Dumazet wrote:
> Even on a Jaguar, the proposed alternative
I don't know what Jaguar you guys are talking about but the Jaguar
I know - Fam16h - has an int hardware divider:
http://developer.amd.com/wordpress/media/2012/10/SOG_16h_52128_PUB_Rev1_1.pdf
So all that talk about microcode is plain wrong. The hardware divider
comes from Llano (F12h) so it must be some other Jaguar, maybe Bobcat.
:-)
If it is Bobcat, then it has a 1-bit per cycle ucode int divider.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply
* Re: [PATCH net-next v3 2/2] stmmac: Fix kernel crashes for jumbo frames
From: Ben Hutchings @ 2014-01-14 23:20 UTC (permalink / raw)
To: Vince Bridgers
Cc: devicetree, netdev, Giuseppe CAVALLARO, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, Kumar Gala, Dinh Nguyen,
Rayagond Kokatanur
In-Reply-To: <CAOwfj2Ne1oRU1z6BaH4g2_EJJFtJOWbgs2oMzSq5nNpz9G6LsA@mail.gmail.com>
On Tue, 2014-01-14 at 14:44 -0600, Vince Bridgers wrote:
> On Tue, Jan 14, 2014 at 1:53 PM, Ben Hutchings
[...]
> >>
> >> /*
> >> * Currently only the properties needed on SPEAr600
> >> @@ -60,6 +64,7 @@ static int stmmac_probe_config_dt(struct platform_device *pdev,
> >> if (of_device_is_compatible(np, "st,spear600-gmac") ||
> >> of_device_is_compatible(np, "snps,dwmac-3.70a") ||
> >> of_device_is_compatible(np, "snps,dwmac")) {
> >> + of_property_read_u32(np, "max-frame-size", &plat->maxmtu);
> > [...]
> >
> > Is it the maximum frame size, including Ethernet header? (And then, is
> > the CRC or any VLAN header included in the frame size?)
> > Or is it the MTU, excluding all of those?
> > You really need to be very clear about what this number represents.
>
> max-frame-size as read from the device tree is defined in the ePAPR
> v1.1 specification. I originally used a name of "max-mtu", but was
> asked to change that since this attribute was already defined in the
> ePAPR v1.1 specification.
[...]
Oh dear, this specification is just as confused as I am. The example
value in §6.3.1.4 is 1518, implying that it is really the frame size,
including the Ethernet header, any VLAN tag, and maybe the CRC. However
the full example in Appendix B1 has 0x5dc (== 1500) implying that it is
the MTU.
I suppose you should follow whatever interpretation is already used by
other drivers. :-/
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Compensation Award !
From: Ruben Alberto Jimenez Cuentas @ 2014-01-14 23:06 UTC (permalink / raw)
Compensation Grant of $5,000,000.00
USD...Contact:mrspatriciapowell@gmail.com for claims.
El presente correo no representa la opinión o consentimiento oficial por parte de la Universidad del Norte por lo que no adquiere responsabilidad alguna por el contenido del presente mensaje salvo en los casos de funcionarios de la Institución en ejercicio de sus atribuciones reglamentarias. Este correo puede provenir de una cuenta que la Universidad ofrece a los estudiantes como parte del servicio educativo o de funcionarios de la Institución, evento en el cual tanto el mensaje como sus anexos son estrictamente confidenciales. Este mensaje ha sido verificado con software antivirus; no obstante lo anterior, la Universidad del Norte no garantiza que sea seguro o no contenga errores o virus por lo que no se hace responsable de su transmisión.
^ permalink raw reply
* [RFC PATCH net-next] etherdevice: Use ether_addr_copy to copy an Ethernet address
From: Joe Perches @ 2014-01-14 23:18 UTC (permalink / raw)
To: netdev; +Cc: linux-arm-kernel, linux-arch
Some systems can use the normally known u16 alignment of
Ethernet addresses to save some code/text bytes and cycles.
This does not change currently emitted code on x86 by gcc 4.8.
Signed-off-by: Joe Perches <joe@perches.com>
---
Yes, it's a trivial change, but maybe slightly useful...
For instance: with netpoll.c memcpy changed to ether_addr_copy:
arm old (4.6.3):
memcpy(eth->h_source, np->dev->dev_addr, ETH_ALEN);
27e0: e4973042 ldr r3, [r7], #66 ; 0x42
27e4: e2860006 add r0, r6, #6
27e8: e3a02006 mov r2, #6
27ec: e59311e8 ldr r1, [r3, #488] ; 0x1e8
27f0: ebfffffe bl 0 <memcpy>
27f0: R_ARM_CALL memcpy
memcpy(eth->h_dest, np->remote_mac, ETH_ALEN);
27f4: e1a00006 mov r0, r6
27f8: e1a01007 mov r1, r7
27fc: e3a02006 mov r2, #6
2800: ebfffffe bl 0 <memcpy>
2800: R_ARM_CALL memcpy
arm new:
*(u32 *)dst = *(const u32 *)src;
27dc: e5932000 ldr r2, [r3]
27e0: e5802006 str r2, [r0, #6]
*(u16 *)(dst + 4) = *(const u16 *)(src + 4);
27e4: e1d330b4 ldrh r3, [r3, #4]
27e8: e1c030ba strh r3, [r0, #10]
* Please note: dst & src must both be aligned to u16.
*/
static inline void ether_addr_copy(u8 *dst, const u8 *src)
{
#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
*(u32 *)dst = *(const u32 *)src;
27ec: e5953042 ldr r3, [r5, #66] ; 0x42
27f0: e5803000 str r3, [r0]
*(u16 *)(dst + 4) = *(const u16 *)(src + 4);
27f4: e1d534b6 ldrh r3, [r5, #70] ; 0x46
27f8: e1c030b4 strh r3, [r0, #4]
include/linux/etherdevice.h | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
index f344ac0..1f26c55 100644
--- a/include/linux/etherdevice.h
+++ b/include/linux/etherdevice.h
@@ -218,6 +218,28 @@ static inline void eth_hw_addr_random(struct net_device *dev)
}
/**
+ * ether_addr_copy - Copy an Ethernet address
+ * @dst: Pointer to a six-byte array Ethernet address destination
+ * @src: Pointer to a six-byte array Ethernet address source
+ *
+ * Please note: dst & src must both be aligned to u16.
+ */
+static inline void ether_addr_copy(u8 *dst, const u8 *src)
+{
+#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
+ *(u32 *)dst = *(const u32 *)src;
+ *(u16 *)(dst + 4) = *(const u16 *)(src + 4);
+#else
+ u16 *a = (u16 *)dst;
+ const u16 *b = (const u16 *)src;
+
+ a[0] = b[0];
+ a[1] = b[1];
+ a[2] = b[2];
+#endif
+}
+
+/**
* eth_hw_addr_inherit - Copy dev_addr from another net_device
* @dst: pointer to net_device to copy dev_addr to
* @src: pointer to net_device to copy dev_addr from
@@ -229,7 +251,7 @@ static inline void eth_hw_addr_inherit(struct net_device *dst,
struct net_device *src)
{
dst->addr_assign_type = src->addr_assign_type;
- memcpy(dst->dev_addr, src->dev_addr, ETH_ALEN);
+ ether_addr_copy(dst->dev_addr, src->dev_addr);
}
/**
^ permalink raw reply related
* Re: [PATCH net-next] net: replace macros net_random and net_srandom with direct calls to prandom
From: David Miller @ 2014-01-14 23:15 UTC (permalink / raw)
To: aruna.hewapathirane; +Cc: netdev, hannes
In-Reply-To: <1389442559-13097-1-git-send-email-aruna.hewapathirane@gmail.com>
From: Aruna-Hewapathirane <aruna.hewapathirane@gmail.com>
Date: Sat, 11 Jan 2014 07:15:59 -0500
> This patch removes the net_random and net_srandom macros and replaces
> them with direct calls to the prandom ones. As new commits only seem to
> use prandom_u32 there is no use to keep them around.
> This change makes it easier to grep for users of prandom_u32.
>
> Signed-off-by: Aruna-Hewapathirane <aruna.hewapathirane@gmail.com>
> Suggested-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] IPv6: enable TCP to use an anycast address
From: David Miller @ 2014-01-14 23:14 UTC (permalink / raw)
To: hannes; +Cc: fx.lebail, kuznet, netdev, jmorris, yoshfuji, kaber
In-Reply-To: <20140113011146.GG6586@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Mon, 13 Jan 2014 02:11:46 +0100
> Hi!
>
> On Sun, Jan 12, 2014 at 06:53:47AM -0800, François-Xavier Le Bail wrote:
>> On Sat, 1/11/14, Hannes Frederic Sowa <hannes@stressinduktion.org> wrote:
>>
>> > On Sat, Jan 11, 2014 at 05:38:27PM +0400, Alexey Kuznetsov wrote:
>> > > On Sat, Jan 11, 2014 at 5:06 PM, François-Xavier Le Bail
>> > > <fx.lebail@yahoo.com> wrote:
>> > > > Many DNS root-servers use TCP with anycast (IPv4 and IPV6).
>> > >
>> > > Actually, I was alerted by reset processing in your patch, it cannot be right.
>> > >
>> > > Do not you think this must not be enabled for common use? At least
>> > > some separate sysctl disabled by default.
>>
>> > The idea I had, was, that if a socket does knowingly bind to an anycast
>> > address, it is allowed to do so and process queries on it with both TCP and
>> > UDP. I don't think we need a sysctl for that? Anycast addresses are either
>> > pre-defined (e.g. the subnet router anycast address) or specified by a flag
>> > when the administrator adds one. Currently one can only add anycast addresses
>> > either by forwarding and gets the per-subnet anycast address or with a
>> > setsockopt IPV6_JOIN_ANYCAST.
>>
>> > So the problem is what should be allowed when the socket listens on an any
>> > address? Maybe this should be protected by a sysctl?
>>
>> TCP case:
>> With my two patches (the one for bind and this one for tcp), when a
>> SOCK_STREAM socket listen to in6addr_any, the server is able to
>> send TCP reply with unicast or anycast source address, according
>> to the destination address used by the client.
>>
>> dest request unicast => src reply unicast (current behavior)
>> dest resquet anycast => src reply anycast (new)
>>
>> So, I don't think there is a need for a sysctl.
>
> I am still thinking about the RST-case and am a bit unsure here. But I
> currently don't see any problems.
I think this needs much more discussion and analysis before I can really
seriously consider applying this, sorry.
^ permalink raw reply
* Re: [PATCH net-next] ipv6: copy traffic class from ping request to reply
From: David Miller @ 2014-01-14 23:09 UTC (permalink / raw)
To: hannes; +Cc: simon-schneider, netdev
In-Reply-To: <20140111105546.GB30388@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Sat, 11 Jan 2014 11:55:46 +0100
> Suggested-by: Simon Schneider <simon-schneider@gmx.net>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
This matches ipv4 behavior (except ipv4 accomplishes this by adjusting
the ICMP socket TOS value every packet response), so applied, thanks!
^ permalink raw reply
* Re: [Patch net-next] ipv4: register igmp_notifier even when !CONFIG_PROC_FS
From: David Miller @ 2014-01-14 23:04 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, stephen, kaber
In-Reply-To: <1389398985-16198-1-git-send-email-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Fri, 10 Jan 2014 16:09:45 -0800
> We still need this notifier even when we don't config
> PROC_FS.
>
> It should be rare to have a kernel without PROC_FS,
> so just for completeness.
>
> Cc: Stephen Hemminger <stephen@networkplumber.org>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Patrick McHardy <kaber@trash.net>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
This looks a little ugly, but I can't suggest anything better.
Applied, thanks.
^ permalink raw reply
* Re: [Bug 68501] New: llc_fixup_skb considers PDU len including ETH_HLEN
From: David Miller @ 2014-01-14 23:01 UTC (permalink / raw)
To: stephen; +Cc: netdev
In-Reply-To: <20140110151156.37ae2618@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Fri, 10 Jan 2014 15:11:56 -0800
> In below snip of code in llc_fixup_skb we calculate pdulen from
> eth_hdr(skb)->h_proto which contains total length of packet include ETH_HLEN.
>
> <snip>
> 119 if (skb->protocol == htons(ETH_P_802_2)) {
> 120 __be16 pdulen = eth_hdr(skb)->h_proto;
> 121 s32 data_size = ntohs(pdulen) - llc_len;
> 122
> 123 if (data_size < 0 ||
> 124 !pskb_may_pull(skb, data_size))
> 125 return 0;
>
> </snip>
>
>
> Line 121 should be changed to
>
> 121 s32 data_size = ntohs(pdulen) - llc_len - ETH_HLEN;
This can't be right, everything I can find says that the length here is:
the 802.2 packet length - the number of bytes of the 802.2
(LLC and data) portion of the frame, excluding padding
Which imples that the ethernet header length is not included.
^ permalink raw reply
* Re: linux-next: Tree for Jan 14 (lowpan, 802.15.4)
From: Dmitry Eremin-Solenikov @ 2014-01-14 22:54 UTC (permalink / raw)
To: Randy Dunlap, David S. Miller, Marcel Holtmann
Cc: Stephen Rothwell, linux-next, kernel list, linux-zigbee-devel,
Alexander Smirnov, netdev@vger.kernel.org, Jukka Rissanen
In-Reply-To: <52D578A7.8020000@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 638 bytes --]
Hello,
On Tue, Jan 14, 2014 at 9:49 PM, Randy Dunlap <rdunlap@infradead.org> wrote:
>
> On 01/13/2014 09:51 PM, Stephen Rothwell wrote:
> > Hi all,
> >
> > This tree fails (more than usual) the powerpc allyesconfig build.
> >
> > Changes since 20140113:
> >
>
>
> on i386:
>
> net/built-in.o: In function `header_create':
> 6lowpan.c:(.text+0x166149): undefined reference to `lowpan_header_compress'
> net/built-in.o: In function `bt_6lowpan_recv':
> (.text+0x166b3c): undefined reference to `lowpan_process_data'
Ah, nice Makefile hack there.
David, Marcel, could you please consider the attached patch.
--
With best wishes
Dmitry
[-- Attachment #2: 0001-net-move-6lowpan-compression-code-to-separate-module.patch --]
[-- Type: text/x-patch, Size: 2784 bytes --]
From 4c3db6d3c244decf434665c30c1bf75aad1f94b2 Mon Sep 17 00:00:00 2001
From: Dmitry Eremin-Solenikov <dmitry_eremin@mentor.com>
Date: Wed, 15 Jan 2014 02:50:40 +0400
Subject: [PATCH] net: move 6lowpan compression code to separate module
IEEE 802.15.4 and Bluetooth networking stacks share 6lowpan compression
code. Instead of introducing Makefile/Kconfig hacks, build this code as
a separate module referenced from both ieee802154 and bluetooth modules.
This fixes the following build error observed in some kernel
configurations:
net/built-in.o: In function `header_create': 6lowpan.c:(.text+0x166149): undefined reference to `lowpan_header_compress'
net/built-in.o: In function `bt_6lowpan_recv': (.text+0x166b3c): undefined reference to `lowpan_process_data'
Signed-off-by: Dmitry Eremin-Solenikov <dmitry_eremin@mentor.com>
---
net/Makefile | 2 +-
net/bluetooth/Kconfig | 1 +
net/ieee802154/Kconfig | 7 +++++++
net/ieee802154/Makefile | 3 ++-
4 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/net/Makefile b/net/Makefile
index 8fa2f91..cbbbe6d 100644
--- a/net/Makefile
+++ b/net/Makefile
@@ -57,7 +57,7 @@ obj-$(CONFIG_CAIF) += caif/
ifneq ($(CONFIG_DCB),)
obj-y += dcb/
endif
-obj-$(CONFIG_IEEE802154) += ieee802154/
+obj-y += ieee802154/
obj-$(CONFIG_MAC802154) += mac802154/
ifeq ($(CONFIG_NET),y)
diff --git a/net/bluetooth/Kconfig b/net/bluetooth/Kconfig
index d3f3f7b..985b560 100644
--- a/net/bluetooth/Kconfig
+++ b/net/bluetooth/Kconfig
@@ -12,6 +12,7 @@ menuconfig BT
select CRYPTO_AES
select CRYPTO_ECB
select CRYPTO_SHA256
+ select 6LOWPAN_IPHC
help
Bluetooth is low-cost, low-power, short-range wireless technology.
It was designed as a replacement for cables and other short-range
diff --git a/net/ieee802154/Kconfig b/net/ieee802154/Kconfig
index b2e06df..9c9879d 100644
--- a/net/ieee802154/Kconfig
+++ b/net/ieee802154/Kconfig
@@ -13,5 +13,12 @@ config IEEE802154
config IEEE802154_6LOWPAN
tristate "6lowpan support over IEEE 802.15.4"
depends on IEEE802154 && IPV6
+ select 6LOWPAN_IPHC
---help---
IPv6 compression over IEEE 802.15.4.
+
+config 6LOWPAN_IPHC
+ tristate
+ ---help---
+ 6lowpan compression code which is shared between IEEE 802.15.4 and Bluetooth
+ stacks.
diff --git a/net/ieee802154/Makefile b/net/ieee802154/Makefile
index 951a83e..e8f0588 100644
--- a/net/ieee802154/Makefile
+++ b/net/ieee802154/Makefile
@@ -1,5 +1,6 @@
obj-$(CONFIG_IEEE802154) += ieee802154.o af_802154.o
-obj-$(CONFIG_IEEE802154_6LOWPAN) += 6lowpan.o 6lowpan_iphc.o
+obj-$(CONFIG_IEEE802154_6LOWPAN) += 6lowpan.o
+obj-$(CONFIG_6LOWPAN_IPHC) += 6lowpan_iphc.o
ieee802154-y := netlink.o nl-mac.o nl-phy.o nl_policy.o wpan-class.o
af_802154-y := af_ieee802154.o raw.o dgram.o
--
1.8.5.2
^ permalink raw reply related
* Re: [PATCH RFC] reciprocal_divide: correction/update of the algorithm
From: Eric Dumazet @ 2014-01-14 22:45 UTC (permalink / raw)
To: Austin S Hemmelgarn
Cc: Hannes Frederic Sowa, netdev, dborkman, linux-kernel,
darkjames-ws
In-Reply-To: <52D5A3DC.9030107@gmail.com>
On Tue, 2014-01-14 at 15:53 -0500, Austin S Hemmelgarn wrote:
> On 2014-01-14 14:50, Eric Dumazet wrote:
> > On Tue, 2014-01-14 at 14:22 -0500, Austin S Hemmelgarn wrote:
> >
> >> I disagree with the statement that current CPU's have reasonably fast
> >> dividers. A lot of embedded processors and many low-end x86 CPU's do
> >> not in-fact have any hardware divider, and usually provide it using
> >> microcode based emulation if they provide it at all. The AMD Jaguar
> >> micro-architecture in particular comes to mind, it uses an iterative
> >> division algorithm provided by the microcode that only produces 2 bits
> >> of quotient per cycle, even in the best case (2 8-bit integers and an
> >> integral 8-bit quotient) this still takes 4 cycles, which is twice as
> >> slow as any other math operation on the same processor.
> >
> > I doubt you run any BPF filter with a divide instruction in it on these
> > platform.
> >
> > Get real, do not over optimize things where it does not matter.
> >
> Actually, I have three Jaguar based routers, and use BPF regularly as
> part of their iptables rules to log certain packet types.
1) Have you enabled BPF JIT
2) Do you have divide instructions in a BPF filter,
if yes, I would like to have an example.
(current code works well for small divisors anyway)
3) How much time is spent in BPF compared to the rest of the stack,
especially if you run iptables...
Spending 2 or 3 days of work to save ~7 cycles for a divide that
probably can be replaced by a shift anyway, while spending 5000 cycles
per packet is what I call not a wise optimization, especially
if dealing with old hardware.
Even on a Jaguar, the proposed alternative
+ u32 t = (u32)(((u64)a * R.m) >> 32);
+ return (t + ((a - t) >> R.sh1)) >> R.sh2;
will have a similar cost.
^ permalink raw reply
* [Patch net-next] net_sched: act: fix a bug in tcf_register_action()
From: Cong Wang @ 2014-01-14 22:48 UTC (permalink / raw)
To: netdev; +Cc: Jamal Hadi Salim, David S. Miller, Cong Wang
In tcf_register_action() we check ->type and ->kind to see if there
is an existing action registered, but ipt action registers two
actions with same type but different kinds. This should be a valid
case, otherwise only xt can be registered.
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index 35f89e9..2070ee3 100644
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -273,7 +273,7 @@ int tcf_register_action(struct tc_action_ops *act)
write_lock(&act_mod_lock);
list_for_each_entry(a, &act_base, head) {
- if (act->type == a->type || (strcmp(act->kind, a->kind) == 0)) {
+ if (act->type == a->type && (strcmp(act->kind, a->kind) == 0)) {
write_unlock(&act_mod_lock);
return -EEXIST;
}
^ permalink raw reply related
* Re: [PATCH net-next 0/3] Improve tracing at the driver/core boundary
From: David Miller @ 2014-01-14 22:47 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1389392139.2025.123.camel@bwh-desktop.uk.level5networks.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Fri, 10 Jan 2014 22:15:39 +0000
> These patches add static tracpeoints at the driver/core boundary which
> record various skb fields likely to be useful for datapath debugging.
> On the TX side the boundary is where the core calls ndo_start_xmit, and
> on the RX side it is where any of the various exported receive functions
> is called.
>
> The set of skb fields is mostly based on what I thought would be
> interesting for sfc.
>
> These patches are basically the same as what I sent as an RFC in
> November, but rebased. They now depend on 'net: core: explicitly select
> a txq before doing l2 forwarding', so please merge net into net-next
> before trying to apply them. The first patch fixes a code formatting
> error left behind after that fix.
This looks great, series applied, thanks Ben.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox