Re: [PATCH] tcp: use kmalloc() than kmalloc_array().
David Miller wrote: > From: Eric Dumazet > Date: Sat, 07 Nov 2015 10:50:07 -0800 > > > I do not feel we should go back to kmalloc() just because > > vmalloc_array() does not exist yet. > > Agreed. > Please change as you like. I was thinking to introduce a helper that does vmalloc() when kmalloc() failed because locations that do ptr = kmalloc(size, GFP_NOFS); if (!ptr) ptr = vmalloc(size); /* Wrong because GFP_KERNEL is used implicitly */ are found. I just noticed that inet_ehash_locks_alloc() is doing ptr = kmalloc_array(count, size, GFP_KERNEL); if (!ptr) ptr = vmalloc(count * size); /* Wrong because overflow is not checked */ and wanted to know your intent. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AF_PACKET mmap() v4...
On 15-11-07 06:19 PM, Alexei Starovoitov wrote: > On Thu, Nov 05, 2015 at 10:39:15AM +0100, Daniel Borkmann wrote: >> On 11/05/2015 10:07 AM, Arnd Bergmann wrote: >>> On Thursday 05 November 2015 00:04:14 David Miller wrote: As part of fixing y2038 problems, Arnd is going to have to make a new version fo the AF_PACKET mmap() tpacker descriptors in order to extend the time values to 64-bit. > > would also be quite useful to add ability to attach metadata to packet > from bpf program. > Right now we can only trim the length. Would be great if program could > compute something and pass it along with packet as metadata. Also most modern NICs can generate metadata using packet filters it would be nice to allow these to populate any metadata fields as well. Ethtool already has a flow classifier feature that could be easily extended once the stack has support. .John > > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majord...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bpf: doc: correct arch list for supported eBPF JIT
On Fri, Nov 06, 2015 at 09:38:58PM -0800, Yang Shi wrote: > aarch64 and s390x support eBPF JIT too, correct document to reflect this and > avoid any confusion. > > Signed-off-by: Yang Shi Thanks Acked-by: Alexei Starovoitov -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm64: bpf: fix JIT stack setup
On Fri, Nov 06, 2015 at 09:36:17PM -0800, Yang Shi wrote: > ARM64 JIT used FP (x29) as eBPF fp register, but FP is subjected to > change during function call so it may cause the BPF prog stack base address > change too. Whenever, it pointed to the bottom of BPF prog stack instead of > the top. > > So, when copying data via bpf_probe_read, it will be copied to (SP - offset), > then it may overwrite the saved FP/LR. > > Use x25 to replace FP as BPF stack base register (fp). Since x25 is callee > saved register, so it will keep intact during function call. > It is initialized in BPF prog prologue when BPF prog is started to run > everytime. When BPF prog exits, it could be just tossed. > > Other than this the BPf prog stack base need to be setup before function > call stack. > > So, the BPF stack layout looks like: > > high > original A64_SP => 0:+-+ BPF prologue > | | FP/LR and callee saved registers > BPF fp register => +64:+-+ > | | > | ... | BPF prog stack > | | > | | > current A64_SP => +-+ > | | > | ... | Function call stack > | | > +-+ > low > > Signed-off-by: Yang Shi > CC: Zi Shen Lim > CC: Xi Wang Thanks for tracking it down. That looks like fundamental bug in arm64 jit. I'm surprised function calls worked at all. Zi please review. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AF_PACKET mmap() v4...
On Thu, Nov 05, 2015 at 10:39:15AM +0100, Daniel Borkmann wrote: > On 11/05/2015 10:07 AM, Arnd Bergmann wrote: > >On Thursday 05 November 2015 00:04:14 David Miller wrote: > >>As part of fixing y2038 problems, Arnd is going to have to make a new > >>version fo the AF_PACKET mmap() tpacker descriptors in order to extend > >>the time values to 64-bit. would also be quite useful to add ability to attach metadata to packet from bpf program. Right now we can only trim the length. Would be great if program could compute something and pass it along with packet as metadata. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bpf: doc: correct arch list for supported eBPF JIT
On 11/07/2015 06:38 AM, Yang Shi wrote: aarch64 and s390x support eBPF JIT too, correct document to reflect this and avoid any confusion. Signed-off-by: Yang Shi Acked-by: Daniel Borkmann -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net 1/2] packet: do skb_probe_transport_header when we actually have data
On 11/07/2015 08:06 PM, Eric Dumazet wrote: On Sat, 2015-11-07 at 10:53 -0800, Eric Dumazet wrote: Well, imagine following scenario (a real one, as I use it all of time, thus how I discovered all trafgen traffic ends up on one slave only) Even if qdisc is bypassed on the bond0, the current handling does not prevent going to the slave qdiscs. So it is not clear to me why we do a selective probe depending on the bypass of first qdisc. Presumably the transport_header only needs to be set for gso packets in some drivers (look at igbvf_tso() for example) It looks like we might need an audit and/or some guidelines/fixes. Hmm, yeah, on a (only quick) look, it seems this is mostly needed for the virtio_net related code in packet_snd() / packet_recvmsg(), not handled in RX/TX ring paths actually. $ git grep -n gso_size net/packet/ net/packet/af_packet.c:2748:if (vnet_hdr.gso_size == 0) net/packet/af_packet.c:2825:skb_shinfo(skb)->gso_size = net/packet/af_packet.c:2826:__virtio16_to_cpu(vio_le(), vnet_hdr.gso_size); net/packet/af_packet.c:3219:vnet_hdr.gso_size = net/packet/af_packet.c:3220: __cpu_to_virtio16(vio_le(), sinfo->gso_size); Need to take a closer look on Monday. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSO with udp_tunnel_xmit_skb
> What I was thinking about is this: My driver receives a super-packet. > By calling skb_gso_segment(), I'm given a list of equal sized packets > (of gso_size each), except for the last one which is either the same > size or smaller than the rest. Let's say calling skb_gso_segment() > gives me a list of 1300 byte packets. This isn't particularly efficient. This is basically equivalent to doing GSO before the superpacket reaches your driver (you might get some savings by not bothering to look at the packet headers of the second and on packets, but that's most likely minimal savings). In particular you're allocating a new skb and clearing it for each of those 1300 byte packets (and deallocating the superpacket skb). And then you are presumably deallocating all those freshly allocated skbs - since I'm guessing you are creating new skbs for transmit. What you really want to do (although of course it's much harder) is not call skb_gso_segment() at all for packet formats you know how to handle (ideally you can handle anything you claim to be able to handle via the features bits) and instead reach directly into the skb and grab the right portions of it and handle them directly. This way you only ever have the one incoming skb, but yes it requires considerable effort. This should get you a fair bit of savings. > Next, I do a particular > transformation to the packet. Let's say I encrypt it somehow, and I > add on some additional information. Now all those 1300 byte packets > yield new 1400 byte packets. It is time to send those 1400 byte > packets to a particular destination. Are you in control of the receiver? Can you modify packet format? > Since they're all children of the > same skb_gso_segment()ified packet, they're all destined for the same > destination. So, one solution is to do this: > > for each skb in list: > udp_tunnel_xmit_skb(dst, skb); > > But this does not perform how I'd like it to perform. The reason is > that now each and every one of these packets has to traverse the whole > networking stack, including various netfilter postrouting hooks and > such, but most importantly, it means the ethernet driver that's > sending the physical packet has to process each and every one. Theoretically you could manually add the proper headers to each of the new packets, and create a chain and send that, although honestly I'm not sure if the stack is at all capable of dealing with that atm. Alternatively instead of sending through the stack, put on full ethernet headers and send straight to the nic via the nic's xmit function. > My hope was that instead of doing the `for each` above, I could > instead do something like: > > superpacket->gso_size = 1400 > for each skb in list: > add_to_superpacket_as_ufo(skb, superpacket); > udp_tunnel_xmit_skb(dst, superpacket); UFO = UDP Fragmentation Offload = really meaning 'UDP transmit checksum offload + IP fragmentation offload' so when you send that out you get ip fragments of 1 udp packet, not many individual udp packets. > And that way, the superpacket would only have to traverse the > networking stack once, leaving it either to the final ethernet driver > to send in a big chunk to the ethernet card, or to the > skb_gso_segment() call in core.c's validate_xmit_skb(). > Is this conceptually okay? What you wrote would seem to indicate it > doesn't make sense conceptually, but I'm not sure. This definitely doesn't make sense with UFO. --- It is possible some hardware (possibly some intel nics, maybe bnx2x) could be tricked into doing udp segmentation with their tcp segmentation engine. Theoretically (based on having glanced at the datasheets) the intel nic segmentation is pretty generic, and it would appear at first glance that with the right driver hacks (populating the transmit descriptor correctly) it could be made to work. I mention bnx2x because they managed to make tcp segmentation work with tunnels, so it's possible that the support is generic enough for it to be possible (with driver changes). Who knows. It may or may not require putting on a fake 20 byte TCP header. There's some tunnel spec that basically does that (should be able to find an RFC online [perhaps I'm thinking of STT - Stateless Transport Tunneling]. I don't think there is currently any way to setup a linux skb with the right metadata for it to just happen though. It does seem like something that could be potentially worth adding though. > So you mean to say UFO is mostly useful for just IP fragmentation? > Don't some NICs also generate individual UDP packets when you pass it > a big buffer of multiple pieces of data all at once? I'm not actually aware of any nics doing that. It's possible if you take an IP/TCP TSO superpacket and stuff an extra IP/UDP header on it the existing tunnel offload stuff in the kernel might make that happen with some nics. Unsure though (as in unsure whether IP/UDP tunneling is currently supported, I know IP/GRE is). -- To unsubscribe
Re: GSO with udp_tunnel_xmit_skb
Hi Maciej, Thanks for your reply. Some interesting things to consider here... See inline below. On Sat, Nov 7, 2015 at 6:19 PM, Maciej Żenczykowski wrote: > > UFO will never collapse multiple (UDP) packets. > > It would be incorrect to do so, since UDP has to maintain packet > framing boundaries, and the only way to mark that on the wire is via > individual appropriately sized packets. What I was thinking about is this: My driver receives a super-packet. By calling skb_gso_segment(), I'm given a list of equal sized packets (of gso_size each), except for the last one which is either the same size or smaller than the rest. Let's say calling skb_gso_segment() gives me a list of 1300 byte packets. Next, I do a particular transformation to the packet. Let's say I encrypt it somehow, and I add on some additional information. Now all those 1300 byte packets yield new 1400 byte packets. It is time to send those 1400 byte packets to a particular destination. Since they're all children of the same skb_gso_segment()ified packet, they're all destined for the same destination. So, one solution is to do this: for each skb in list: udp_tunnel_xmit_skb(dst, skb); But this does not perform how I'd like it to perform. The reason is that now each and every one of these packets has to traverse the whole networking stack, including various netfilter postrouting hooks and such, but most importantly, it means the ethernet driver that's sending the physical packet has to process each and every one. My hope was that instead of doing the `for each` above, I could instead do something like: superpacket->gso_size = 1400 for each skb in list: add_to_superpacket_as_ufo(skb, superpacket); udp_tunnel_xmit_skb(dst, superpacket); And that way, the superpacket would only have to traverse the networking stack once, leaving it either to the final ethernet driver to send in a big chunk to the ethernet card, or to the skb_gso_segment() call in core.c's validate_xmit_skb(). Is this conceptually okay? What you wrote would seem to indicate it doesn't make sense conceptually, but I'm not sure. I started to write some code to do that, which isn't really working, and I outlined it here [1]. > UFO prevents the need to do IP fragmentation on overly large > *singular* UDP packets. > > The case where UFO (should) help is if you are taking a TCP TSO > segment of 10k and adding UDP headers and sending it out as an > 20+8+10k UDP packet. > Without UFO this would now need to be software (potentially > checksummed and) ip fragmented into (8+10k)/(1500-20) packets > (assuming 1500 mtu), with UFO hw offload the nic deals with that (it > does the checksumming and it does the ip fragmentation). So you mean to say UFO is mostly useful for just IP fragmentation? Don't some NICs also generate individual UDP packets when you pass it a big buffer of multiple pieces of data all at once? Thanks, Jason [1] http://www.spinics.net/lists/netdev/msg351400.html -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net 1/2] packet: do skb_probe_transport_header when we actually have data
From: Eric Dumazet Date: Sat, 07 Nov 2015 10:53:50 -0800 > Well, imagine following scenario (a real one, as I use it all of > time, thus how I discovered all trafgen traffic ends up on one slave > only) > > Even if qdisc is bypassed on the bond0, the current handling does > not prevent going to the slave qdiscs. Ok, depending upon the semantics Daniel intended, we may have to add a qdisc bypass boolean bit to SKBs. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4.3.0 r8169: "rtl_counters_cond == 1 (loop: 1000, delay: 10)." log spam
Sverd Johnsen :
> related:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=107421
Let's start with yours.
> https://bugzilla.kernel.org/show_bug.cgi?id=104351
>
> 4.3.0 smp x86_64
>
> [4.384336] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> [4.384747] r8169 :0e:00.0 eth0: RTL8101e at
> 0xc906, 00:1b:38:b5:9f:d6, XID 9420 IRQ 29
> [ 13.288711] r8169 :0e:00.0 enp14s0: renamed from eth0
> [ 13.317747] r8169 :0e:00.0 enp14s0: rtl_counters_cond == 1
> (loop: 1000, delay: 10).
> [ 28.238567] r8169 :0e:00.0 enp14s0: rtl_counters_cond == 1
> (loop: 1000, delay: 10).
> [ 28.904171] r8169 :0e:00.0 enp14s0: rtl_counters_cond == 1
> (loop: 1000, delay: 10).
> [ 28.923315] r8169 :0e:00.0 enp14s0: rtl_counters_cond == 1
> (loop: 1000, delay: 10).
> [ 29.029901] r8169 :0e:00.0 enp14s0: rtl_counters_cond == 1
> (loop: 1000, delay: 10).
[snip]
> [ 36.148587] r8169 :0e:00.0 enp14s0: rtl_counters_cond == 1
> (loop: 1000, delay: 10).
Something enjoys harnessing the tally counters. I don't know why.
> [ 46.511024] r8169 :0e:00.0 enp14s0: rtl_counters_cond == 1
> (loop: 1000, delay: 10).
> [ 48.304603] r8169 :0e:00.0 enp14s0: rtl_counters_cond == 1
> (loop: 1000, delay: 10).
> [ 61.528387] r8169 :0e:00.0 enp14s0: rtl_counters_cond == 1
> (loop: 1000, delay: 10).
> [ 76.545869] r8169 :0e:00.0 enp14s0: rtl_counters_cond == 1
> (loop: 1000, delay: 10).
Looks like stats retrieval every 15s.
Is the link up at this point ?
Can you temporarily increase the driver verbosity ? It may display
some more messages at WARNING level if you enable "hw" context messages
through ethtool (see "msglvl" option).
Btw the patch below could make a difference.
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/realtek/r8169.c
index b4f2123..b9817fec 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -2194,8 +2194,12 @@ static int rtl8169_get_sset_count(struct net_device
*dev, int sset)
DECLARE_RTL_COND(rtl_counters_cond)
{
void __iomem *ioaddr = tp->mmio_addr;
+ u32 mask = CounterReset;
- return RTL_R32(CounterAddrLow) & (CounterReset | CounterDump);
+ if (tp->mac_version >= RTL_GIGA_MAC_VER_19)
+ mask |= CounterDump;
+
+ return RTL_R32(CounterAddrLow) & mask;
}
static bool rtl8169_do_counters(struct net_device *dev, u32 counter_cmd)
--
Ueimor
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next network throughput performance regression
On Sat, 2015-11-07 at 11:35 -0800, Eric Dumazet wrote: > On Fri, 2015-11-06 at 14:30 -0700, David Ahern wrote: > > On 11/6/15 2:18 PM, Simon Xiao wrote: > > > The .config file used to build linux-next kernel is attached to this mail. > > > > Thanks. > > > > Failed to notice this on the first response; my brain filled in. Why > > linux-next tree? Can you try net-next which is more relevant for this > > mailing list, post the top commit id and config file used? > > Throughput on a single TCP flow for a 40G NIC can be tricky to tune. > > Make sure IRQ are properly setup/balanced, as I know that IRQ names were > changed recently and your scripts might have not noticed... > > Also "ethtool -c eth0" might show very different interrupt coalescing > params ? > > I too have a Mellanox 40Gb in my lab and saw no difference in > performance with recent kernels. > > Of course, a simple "perf record -a -g sleep 4 ; perf report" might > point to some obvious issue. Like unexpected segmentation in case of > forwarding... > > I did a test with current net tree on both sender and receiver lpaa23:~# ./netperf -H 10.246.7.152 MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.246.7.152 () port 0 AF_INET Recv SendSend Socket Socket Message Elapsed Size SizeSize Time Throughput bytes bytes bytessecs.10^6bits/sec 87380 16384 1638410.0026864.98 lpaa23:~# ethtool -c eth1 Coalesce parameters for eth1: Adaptive RX: on TX: off stats-block-usecs: 0 sample-interval: 0 pkt-rate-low: 40 pkt-rate-high: 45 rx-usecs: 16 rx-frames: 44 rx-usecs-irq: 0 rx-frames-irq: 0 tx-usecs: 16 tx-frames: 16 tx-usecs-irq: 0 tx-frames-irq: 256 rx-usecs-low: 0 rx-frame-low: 0 tx-usecs-low: 0 tx-frame-low: 0 rx-usecs-high: 128 rx-frame-high: 0 tx-usecs-high: 0 tx-frame-high: 0 lpaa23:~# ethtool -C eth1 tx-usecs 4 tx-frames 4 lpaa23:~# ./netperf -H 10.246.7.152 MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.246.7.152 () port 0 AF_INET Recv SendSend Socket Socket Message Elapsed Size SizeSize Time Throughput bytes bytes bytessecs.10^6bits/sec 87380 16384 1638410.0030206.27 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] drivers: net: xgene: fix RGMII 10/100Mb mode
This patch fixes the RGMII 10/100M mode by reprogramming the clock.
Signed-off-by: Iyappan Subramanian
Tested-by: Fushen Chen
---
v2: Address v1 review comments
- targeting bug fix patch to "net" tree
v1: Initial revision
---
drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 49 +++-
drivers/net/ethernet/apm/xgene/xgene_enet_hw.h | 1 +
drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 1 -
3 files changed, 48 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
index 33850a0..c31e691 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
@@ -459,6 +459,45 @@ static void xgene_gmac_reset(struct xgene_enet_pdata
*pdata)
xgene_enet_wr_mcx_mac(pdata, MAC_CONFIG_1_ADDR, 0);
}
+static void xgene_enet_configure_clock(struct xgene_enet_pdata *pdata)
+{
+ struct device *dev = &pdata->pdev->dev;
+
+ if (dev->of_node) {
+ struct clk *parent = clk_get_parent(pdata->clk);
+
+ switch (pdata->phy_speed) {
+ case SPEED_10:
+ clk_set_rate(parent, 250);
+ break;
+ case SPEED_100:
+ clk_set_rate(parent, 2500);
+ break;
+ default:
+ clk_set_rate(parent, 12500);
+ break;
+ }
+ }
+#ifdef CONFIG_ACPI
+ else {
+ switch (pdata->phy_speed) {
+ case SPEED_10:
+ acpi_evaluate_object(ACPI_HANDLE(dev),
+"S10", NULL, NULL);
+ break;
+ case SPEED_100:
+ acpi_evaluate_object(ACPI_HANDLE(dev),
+"S100", NULL, NULL);
+ break;
+ default:
+ acpi_evaluate_object(ACPI_HANDLE(dev),
+"S1G", NULL, NULL);
+ break;
+ }
+ }
+#endif
+}
+
static void xgene_gmac_init(struct xgene_enet_pdata *pdata)
{
struct device *dev = &pdata->pdev->dev;
@@ -477,12 +516,14 @@ static void xgene_gmac_init(struct xgene_enet_pdata
*pdata)
switch (pdata->phy_speed) {
case SPEED_10:
ENET_INTERFACE_MODE2_SET(&mc2, 1);
+ intf_ctl &= ~(ENET_LHD_MODE | ENET_GHD_MODE);
CFG_MACMODE_SET(&icm0, 0);
CFG_WAITASYNCRD_SET(&icm2, 500);
rgmii &= ~CFG_SPEED_1250;
break;
case SPEED_100:
ENET_INTERFACE_MODE2_SET(&mc2, 1);
+ intf_ctl &= ~ENET_GHD_MODE;
intf_ctl |= ENET_LHD_MODE;
CFG_MACMODE_SET(&icm0, 1);
CFG_WAITASYNCRD_SET(&icm2, 80);
@@ -490,12 +531,15 @@ static void xgene_gmac_init(struct xgene_enet_pdata
*pdata)
break;
default:
ENET_INTERFACE_MODE2_SET(&mc2, 2);
+ intf_ctl &= ~ENET_LHD_MODE;
intf_ctl |= ENET_GHD_MODE;
-
+ CFG_MACMODE_SET(&icm0, 2);
+ CFG_WAITASYNCRD_SET(&icm2, 0);
if (dev->of_node) {
CFG_TXCLK_MUXSEL0_SET(&rgmii, pdata->tx_delay);
CFG_RXCLK_MUXSEL0_SET(&rgmii, pdata->rx_delay);
}
+ rgmii |= CFG_SPEED_1250;
xgene_enet_rd_csr(pdata, DEBUG_REG_ADDR, &value);
value |= CFG_BYPASS_UNISEC_TX | CFG_BYPASS_UNISEC_RX;
@@ -503,7 +547,7 @@ static void xgene_gmac_init(struct xgene_enet_pdata *pdata)
break;
}
- mc2 |= FULL_DUPLEX2;
+ mc2 |= FULL_DUPLEX2 | PAD_CRC;
xgene_enet_wr_mcx_mac(pdata, MAC_CONFIG_2_ADDR, mc2);
xgene_enet_wr_mcx_mac(pdata, INTERFACE_CONTROL_ADDR, intf_ctl);
@@ -522,6 +566,7 @@ static void xgene_gmac_init(struct xgene_enet_pdata *pdata)
/* Rtype should be copied from FP */
xgene_enet_wr_csr(pdata, RSIF_RAM_DBG_REG0_ADDR, 0);
xgene_enet_wr_csr(pdata, RGMII_REG_0_ADDR, rgmii);
+ xgene_enet_configure_clock(pdata);
/* Rx-Tx traffic resume */
xgene_enet_wr_csr(pdata, CFG_LINK_AGGR_RESUME_0_ADDR, TX_PORT0);
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
index 6dee73c..c153a1d 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
@@ -181,6 +181,7 @@ enum xgene_enet_rm {
#define ENET_LHD_MODE BIT(25)
#define ENET_GHD_MODE BIT(26)
#define FULL_DUPLEX2 BIT(0)
+#define PAD_CRCBIT(2)
#define SCAN_AUTO_INCR BIT(5)
#define TBYT_ADDR
Re: linux-next network throughput performance regression
On Fri, 2015-11-06 at 14:30 -0700, David Ahern wrote: > On 11/6/15 2:18 PM, Simon Xiao wrote: > > The .config file used to build linux-next kernel is attached to this mail. > > Thanks. > > Failed to notice this on the first response; my brain filled in. Why > linux-next tree? Can you try net-next which is more relevant for this > mailing list, post the top commit id and config file used? Throughput on a single TCP flow for a 40G NIC can be tricky to tune. Make sure IRQ are properly setup/balanced, as I know that IRQ names were changed recently and your scripts might have not noticed... Also "ethtool -c eth0" might show very different interrupt coalescing params ? I too have a Mellanox 40Gb in my lab and saw no difference in performance with recent kernels. Of course, a simple "perf record -a -g sleep 4 ; perf report" might point to some obvious issue. Like unexpected segmentation in case of forwarding... -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tcp: use kmalloc() than kmalloc_array().
From: Eric Dumazet Date: Sat, 07 Nov 2015 10:50:07 -0800 > I do not feel we should go back to kmalloc() just because > vmalloc_array() does not exist yet. Agreed. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net 1/2] packet: do skb_probe_transport_header when we actually have data
On Sat, 2015-11-07 at 10:53 -0800, Eric Dumazet wrote: > Well, imagine following scenario (a real one, as I use it all of time, > thus how I discovered all trafgen traffic ends up on one slave only) > > Even if qdisc is bypassed on the bond0, the current handling does not > prevent going to the slave qdiscs. > > > So it is not clear to me why we do a selective probe depending on the > bypass of first qdisc. Presumably the transport_header only needs to be set for gso packets in some drivers (look at igbvf_tso() for example) It looks like we might need an audit and/or some guidelines/fixes. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net 1/2] packet: do skb_probe_transport_header when we actually have data
On Sat, 2015-11-07 at 13:35 -0500, David Miller wrote: > From: Eric Dumazet > Date: Sat, 07 Nov 2015 04:42:56 -0800 > > > The if (!packet_use_direct_xmit(po)) test looks dubious. > > > > Setting transport header has nothing to do with bypassing qdisc ? > > > > This might lead to hard to debug problems, for drivers expecting > > transport header being set ? > > Do we have any such drivers that need it in this scenerio? Well, imagine following scenario (a real one, as I use it all of time, thus how I discovered all trafgen traffic ends up on one slave only) Even if qdisc is bypassed on the bond0, the current handling does not prevent going to the slave qdiscs. So it is not clear to me why we do a selective probe depending on the bypass of first qdisc. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tcp: use kmalloc() than kmalloc_array().
On Sun, 2015-11-08 at 00:50 +0900, Tetsuo Handa wrote:
> Commit 095dc8e0c3686d58 ("tcp: fix/cleanup inet_ehash_locks_alloc()")
> silently changed from kmalloc() to kmalloc_array(). The latter has
> overflow check whereas the former doesn't have.
>
> If nblocks * locksz might overflow, we need to do like
>
> - if (!hashinfo->ehash_locks && nblocks > SIZE_MAX / locksz)
> + if (!hashinfo->ehash_locks && nblocks > SIZE_MAX / locksz)
>hashinfo->ehash_locks = vmalloc(nblocks * locksz);
>
> because kmalloc_array() detects overflow and returns NULL.
> But if nblocks * locksz is guaranteed not to overflow, there is
> no need to use kmalloc_array().
>
> Since I assume it won't overflow, use kmalloc() than kmalloc_array().
>
> Signed-off-by: Tetsuo Handa
> ---
> net/ipv4/inet_hashtables.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c
> index ccc5980..8f4ab27 100644
> --- a/net/ipv4/inet_hashtables.c
> +++ b/net/ipv4/inet_hashtables.c
> @@ -648,8 +648,8 @@ int inet_ehash_locks_alloc(struct inet_hashinfo *hashinfo)
> /* no more locks than number of hash buckets */
> nblocks = min(nblocks, hashinfo->ehash_mask + 1);
>
> - hashinfo->ehash_locks = kmalloc_array(nblocks, locksz,
> - GFP_KERNEL |
> __GFP_NOWARN);
> + hashinfo->ehash_locks = kmalloc(nblocks * locksz,
> + GFP_KERNEL | __GFP_NOWARN);
> if (!hashinfo->ehash_locks)
> hashinfo->ehash_locks = vmalloc(nblocks * locksz);
>
I remember that my initial attempt had been to use size_t for nblocks,
but I realized roundup_pow_of_two() only accepted an 'unsigned long'
Then, presumably I just gave up.
I do not feel we should go back to kmalloc() just because
vmalloc_array() does not exist yet.
Maybe the following would clear things for you guys ?
If it is OK, please Tetsuo submit this patch formally.
Thanks !
diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c
index ccc5980797fc..8f7c71e20089 100644
--- a/net/ipv4/inet_hashtables.c
+++ b/net/ipv4/inet_hashtables.c
@@ -638,15 +638,15 @@ EXPORT_SYMBOL_GPL(inet_hashinfo_init);
int inet_ehash_locks_alloc(struct inet_hashinfo *hashinfo)
{
unsigned int locksz = sizeof(spinlock_t);
- unsigned int i, nblocks = 1;
+ size_t i, nblocks = 1;
if (locksz != 0) {
/* allocate 2 cache lines or at least one spinlock per cpu */
- nblocks = max(2U * L1_CACHE_BYTES / locksz, 1U);
+ nblocks = max_t(size_t, 2 * L1_CACHE_BYTES / locksz, 1);
nblocks = roundup_pow_of_two(nblocks * num_possible_cpus());
/* no more locks than number of hash buckets */
- nblocks = min(nblocks, hashinfo->ehash_mask + 1);
+ nblocks = min_t(size_t, nblocks, hashinfo->ehash_mask + 1);
hashinfo->ehash_locks = kmalloc_array(nblocks, locksz,
GFP_KERNEL |
__GFP_NOWARN);
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net 1/2] packet: do skb_probe_transport_header when we actually have data
From: Eric Dumazet Date: Sat, 07 Nov 2015 04:42:56 -0800 > The if (!packet_use_direct_xmit(po)) test looks dubious. > > Setting transport header has nothing to do with bypassing qdisc ? > > This might lead to hard to debug problems, for drivers expecting > transport header being set ? Do we have any such drivers that need it in this scenerio? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net] bonding: fix panic on non-ARPHRD_ETHER enslave failure
From: Jay Vosburgh
Date: Fri, 06 Nov 2015 17:23:23 -0800
>
> Since commit 7d5cd2ce529b, when bond_enslave fails on devices that
> are not ARPHRD_ETHER, if needed, it resets the bonding device back to
> ARPHRD_ETHER by calling ether_setup.
>
> Unfortunately, ether_setup clobbers dev->flags, clearing IFF_UP
> if the bond device is up, leaving it in a quasi-down state without
> having actually gone through dev_close. For bonding, if any periodic
> work queue items are active (miimon, arp_interval, etc), those will
> remain running, as they are stopped by bond_close. At this point, if
> the bonding module is unloaded or the bond is deleted, the system will
> panic when the work function is called.
>
> This panic is resolved by calling dev_close on the bond itself
> prior to calling ether_setup.
>
> Cc: Nikolay Aleksandrov
> Signed-off-by: Jay Vosburgh
> Fixes: 7d5cd2ce5292 ("bonding: correctly handle bonding type change on
> enslave failure")
Applied and queued up for -stable, thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] decnet: remove macro-local declarations
On Sat, 7 Nov 2015, David Miller wrote: > From: Julia Lawall > Date: Fri, 6 Nov 2015 11:57:34 +0100 (CET) > > >> > Would it be preferable to remove the macro entirely and inline the for > >> > loop header? > >> > >> Could you show me an example of how this would look exactly? > > > > One possible solution is below. I moved the initialization of the nh > > pointer inside the loop to reduce the size of the loop header. One could > > also inline fi->fib_nh[nhsel] where it occurs, but it seemed that that > > would make quite long expressions. > > Personally I like the explicit named iterator. It is descriptive and > tells that we are walking over all of the nexthops for a route. OK, I'll follow that solution. julia -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dwc_eth_qos: Delete an unnecessary check before the function call "of_node_put"
From: SF Markus Elfring Date: Sat, 7 Nov 2015 16:34:48 +0100 > From: Markus Elfring > Date: Sat, 7 Nov 2015 16:30:34 +0100 > > The of_node_put() function tests whether its argument is NULL > and then returns immediately. > Thus the test around the call is not needed. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fjes: Delete an unnecessary check before the function call "vfree"
From: SF Markus Elfring Date: Fri, 6 Nov 2015 09:39:23 +0100 > From: Markus Elfring > Date: Fri, 6 Nov 2015 09:30:29 +0100 > > The vfree() function performs also input parameter validation. > Thus the test around the call is not needed. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] decnet: remove macro-local declarations
From: Julia Lawall Date: Fri, 6 Nov 2015 11:57:34 +0100 (CET) >> > Would it be preferable to remove the macro entirely and inline the for >> > loop header? >> >> Could you show me an example of how this would look exactly? > > One possible solution is below. I moved the initialization of the nh > pointer inside the loop to reduce the size of the loop header. One could > also inline fi->fib_nh[nhsel] where it occurs, but it seemed that that > would make quite long expressions. Personally I like the explicit named iterator. It is descriptive and tells that we are walking over all of the nexthops for a route. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net] net/qlcnic: fix mac address restore in bond mode 5/6
From: Jarod Wilson Date: Fri, 6 Nov 2015 09:25:31 -0500 > The bonding driver saves a copy of slaves' original mac address and then > assigns whatever mac as needed to the slave, depending on mode. In at > least modes 5 and 6 (balance-tlb, balance-alb), it often ends up being the > mac address of another slave. On release from the bond, the original mac > address is supposed to get restored via a dev_set_mac_address() call in > the bonding driver's __bond_release_one() function, which calls the > slave's ndo_set_mac_address function, which for qlcnic, is > qlcnic_set_mac(). > > Now, this function tries to be somewhat intelligent and exit early if > you're trying to set the mac address to the same thing that is already > set. The problem here is that adapter->mac_addr isn't in sync with > netdev->dev_addr. The qlcnic driver still has the original mac stored in > adapter->mac_addr, while the bonding driver has updated netdev->dev_addr, > so qlcnic thinks we're trying to set the same address it already has. > > I think the way to go here, since the function updates both netdev and > adapter's stored mac addresses, is to check if either of them doesn't > match the newly requested mac. Simply checking netdev's value only could > result in a similar mismatch and non-update, so look at both. > > CC: dept-gelinuxnic...@qlogic.com > CC: netdev@vger.kernel.org > CC: Manish Chopra > Signed-off-by: Jarod Wilson Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] inet: delay address promotion check until last request in message
From: Julian Anastasov Date: Sat, 7 Nov 2015 01:49:25 +0200 (EET) > On Fri, 6 Nov 2015, Neil Horman wrote: > >> The solution is to recognize that its pointless to promote an address to be a >> new primary, if there is a possibility that it will just be removed in the >> near >> future. As such this patch peeks ahead to the next request in the provided >> netlink message, and, if it is both valid and a RTM_DELADDR request, skips >> the >> promotion check. This eliminates the need to iterate through a nested for >> loop > > flush can provide many parameters. As there is no > any kind of indication in the netlink message that all addresses > are removed, we can not avoid the promotion. > >> + * Only check for address promotion when this is the last request >> + * in this netlink transaction. It allows this operation to complete >> + * in O(n) time rather than O(n^2) > > It is not correct to assume that one promotion per > transaction is enough. The promotion happens in every subnet, > it was not once per device. Agreed, this optimization is invalid. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tcp: use kmalloc() than kmalloc_array().
From: Tetsuo Handa
Date: Sun, 8 Nov 2015 00:58:50 +0900
> Tetsuo Handa wrote:
>> Commit 095dc8e0c3686d58 ("tcp: fix/cleanup inet_ehash_locks_alloc()")
>> silently changed from kmalloc() to kmalloc_array(). The latter has
>> overflow check whereas the former doesn't have.
>>
>> If nblocks * locksz might overflow, we need to do like
>>
>> - if (!hashinfo->ehash_locks && nblocks > SIZE_MAX / locksz)
>> + if (!hashinfo->ehash_locks && nblocks > SIZE_MAX / locksz)
>
> Oops, I meant
>
>- if (!hashinfo->ehash_locks)
>+ if (!hashinfo->ehash_locks && nblocks > SIZE_MAX / locksz)
>
> here.
>
>>hashinfo->ehash_locks = vmalloc(nblocks * locksz);
>>
>> because kmalloc_array() detects overflow and returns NULL.
>> But if nblocks * locksz is guaranteed not to overflow, there is
>> no need to use kmalloc_array().
>>
>> Since I assume it won't overflow, use kmalloc() than kmalloc_array().
>
> I don't know about possible value range.
> Please confirm that it can't overflow.
Whether it can overflow or not, I don't like your change at all.
If kmalloc_array() provides overflow protection, we want to keep using
it, rather than reverting back to not checking for overflow.
kmalloc_array() can fail for us at this stage for two reasons, either:
1) overflow
2) allocation size exceeds kmalloc() maximum alloc size
so if you want to be completely perfect about all of this you need
to add code to distinguish between these two cases as you suggest
above.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSO with udp_tunnel_xmit_skb
> I suppose this is about UFO. > > Specifically -- let's say I have a list of 500 skbs, which have their > data in place but don't yet have an IP or UDP header etc. I want to > send out these out using udp_tunnel_xmit_skb. Right now, if I just > send them all out, one after another, they don't seem to be getting > assembled into a super packet suitable for UFO. Instead, they're just > sent one at a time, and I get the vast majority of `perf top` CPU > usage in my ethernet card's driver and along the path to it -- the > problem that UFO is supposed to solve. > > So my question is -- how can I make UFO happen with udp_tunnel_xmit_skb? UFO will never collapse multiple (UDP) packets. It would be incorrect to do so, since UDP has to maintain packet framing boundaries, and the only way to mark that on the wire is via individual appropriately sized packets. UFO prevents the need to do IP fragmentation on overly large *singular* UDP packets. The case where UFO (should) help is if you are taking a TCP TSO segment of 10k and adding UDP headers and sending it out as an 20+8+10k UDP packet. Without UFO this would now need to be software (potentially checksummed and) ip fragmented into (8+10k)/(1500-20) packets (assuming 1500 mtu), with UFO hw offload the nic deals with that (it does the checksumming and it does the ip fragmentation). Although note: in the case of UDP+TCP TSO this has reliability issues, since a loss of a single frame will now lose the entire fragmented IP UDP datagram and thus lose the entire TCP TSO segment, meaning that you probably do not want to use this unless your network is lossless (ie. loopback, veth and other virtual networks come to mind). I guess UDP encap of a larger than mtu UDP is probably a valid use case for UFO, since we'd have ip fragmented anyway, and it's cheaper to ip fragment on the outer IP header than on the inner. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] man: Syntax and warning fixes
On 11/7/15 2:55 AM, Ville Skyttä wrote: On Sat, Nov 7, 2015 at 11:47 AM, Albino B Neto wrote: 2015-11-07 7:44 GMT-02:00 Ville Skyttä : --- man/man8/tc-bpf.8 | 2 +- man/man8/tipc-bearer.8| 4 ++-- man/man8/tipc-link.8 | 6 +++--- man/man8/tipc-media.8 | 4 ++-- man/man8/tipc-nametable.8 | 4 ++-- man/man8/tipc-node.8 | 4 ++-- man/man8/tipc-socket.8| 4 ++-- 7 files changed, 14 insertions(+), 14 deletions(-) diff --git a/man/man8/tc-bpf.8 b/man/man8/tc-bpf.8 index 2c02ab2..f5201d3 100644 --- a/man/man8/tc-bpf.8 +++ b/man/man8/tc-bpf.8 @@ -844,7 +844,7 @@ result in the default classid: Basically, such a minimal generator is equivalent to: Signed-off-by and description ? Superseding patches sent separately. I suggest documenting the requirement for Signed-off-by somewhere (README.devel?); git log shows lots of commits without it, especially a bunch of man page related ones about a week ago. I believe man page changes should cc linux-...@vger.kernel.org -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tcp: use kmalloc() than kmalloc_array().
Tetsuo Handa wrote:
> Commit 095dc8e0c3686d58 ("tcp: fix/cleanup inet_ehash_locks_alloc()")
> silently changed from kmalloc() to kmalloc_array(). The latter has
> overflow check whereas the former doesn't have.
>
> If nblocks * locksz might overflow, we need to do like
>
> - if (!hashinfo->ehash_locks && nblocks > SIZE_MAX / locksz)
> + if (!hashinfo->ehash_locks && nblocks > SIZE_MAX / locksz)
Oops, I meant
- if (!hashinfo->ehash_locks)
+ if (!hashinfo->ehash_locks && nblocks > SIZE_MAX / locksz)
here.
>hashinfo->ehash_locks = vmalloc(nblocks * locksz);
>
> because kmalloc_array() detects overflow and returns NULL.
> But if nblocks * locksz is guaranteed not to overflow, there is
> no need to use kmalloc_array().
>
> Since I assume it won't overflow, use kmalloc() than kmalloc_array().
I don't know about possible value range.
Please confirm that it can't overflow.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] tcp: use kmalloc() than kmalloc_array().
Commit 095dc8e0c3686d58 ("tcp: fix/cleanup inet_ehash_locks_alloc()")
silently changed from kmalloc() to kmalloc_array(). The latter has
overflow check whereas the former doesn't have.
If nblocks * locksz might overflow, we need to do like
- if (!hashinfo->ehash_locks && nblocks > SIZE_MAX / locksz)
+ if (!hashinfo->ehash_locks && nblocks > SIZE_MAX / locksz)
hashinfo->ehash_locks = vmalloc(nblocks * locksz);
because kmalloc_array() detects overflow and returns NULL.
But if nblocks * locksz is guaranteed not to overflow, there is
no need to use kmalloc_array().
Since I assume it won't overflow, use kmalloc() than kmalloc_array().
Signed-off-by: Tetsuo Handa
---
net/ipv4/inet_hashtables.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c
index ccc5980..8f4ab27 100644
--- a/net/ipv4/inet_hashtables.c
+++ b/net/ipv4/inet_hashtables.c
@@ -648,8 +648,8 @@ int inet_ehash_locks_alloc(struct inet_hashinfo *hashinfo)
/* no more locks than number of hash buckets */
nblocks = min(nblocks, hashinfo->ehash_mask + 1);
- hashinfo->ehash_locks = kmalloc_array(nblocks, locksz,
- GFP_KERNEL |
__GFP_NOWARN);
+ hashinfo->ehash_locks = kmalloc(nblocks * locksz,
+ GFP_KERNEL | __GFP_NOWARN);
if (!hashinfo->ehash_locks)
hashinfo->ehash_locks = vmalloc(nblocks * locksz);
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dwc_eth_qos: Delete an unnecessary check before the function call "of_node_put"
From: Markus Elfring Date: Sat, 7 Nov 2015 16:30:34 +0100 The of_node_put() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/net/ethernet/synopsys/dwc_eth_qos.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/ethernet/synopsys/dwc_eth_qos.c b/drivers/net/ethernet/synopsys/dwc_eth_qos.c index 85b3326..9066d7a 100644 --- a/drivers/net/ethernet/synopsys/dwc_eth_qos.c +++ b/drivers/net/ethernet/synopsys/dwc_eth_qos.c @@ -2970,8 +2970,7 @@ err_out_unregister_netdev: err_out_clk_dis_aper: clk_disable_unprepare(lp->apb_pclk); err_out_free_netdev: - if (lp->phy_node) - of_node_put(lp->phy_node); + of_node_put(lp->phy_node); free_netdev(ndev); platform_set_drvdata(pdev, NULL); return ret; -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ethernet-synopsys: Delete an unnecessary check before of_node_put()
From: SF Markus Elfring Date: Sat, 7 Nov 2015 15:15:24 +0100 > From: Markus Elfring > Date: Sat, 7 Nov 2015 15:10:29 +0100 > > The of_node_put() function tests whether its argument is NULL and then > returns immediately. Thus the test around the call is not needed. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring As I requested of you last night, please phrase the subsystem prefix of your Subject lines more correctly. Just use the driver's name, in lower case, as one single word, which in this case would be "dwc_eth_qos: ". I'm telling you exactly what to use in the Subject line, there is no ambiguity or confusion on what you need to do for me to accept this patch. Thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ethernet-synopsys: Delete an unnecessary check before of_node_put()
From: Markus Elfring Date: Sat, 7 Nov 2015 15:10:29 +0100 The of_node_put() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/net/ethernet/synopsys/dwc_eth_qos.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/ethernet/synopsys/dwc_eth_qos.c b/drivers/net/ethernet/synopsys/dwc_eth_qos.c index 85b3326..9066d7a 100644 --- a/drivers/net/ethernet/synopsys/dwc_eth_qos.c +++ b/drivers/net/ethernet/synopsys/dwc_eth_qos.c @@ -2970,8 +2970,7 @@ err_out_unregister_netdev: err_out_clk_dis_aper: clk_disable_unprepare(lp->apb_pclk); err_out_free_netdev: - if (lp->phy_node) - of_node_put(lp->phy_node); + of_node_put(lp->phy_node); free_netdev(ndev); platform_set_drvdata(pdev, NULL); return ret; -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] packet: Allow packets with only a header (but no payload)
On 2015-07-31 00:15, Martin Blumenstingl wrote: > On Wed, Jul 29, 2015 at 8:05 AM, Willem de Bruijn wrote: >> Martin, to return to your initial statement that PPPoE PADI packets can >> have a zero payload: the PPPoE RFC states that PADI packets "MUST >> contain exactly one TAG of TAG_TYPE Service-Name, indicating the >> service the Host is requesting, and any number of other TAG types." >> (RFC 2516, 5.1). Is the observed behavior (no payload) perhaps >> incorrect? > As far as I can see you are right, but the real world seems to be different. > My ISP for example lists the PPPoE connection settings, but they are > nowhere mentioning the "service name". > > I have also re-read pppd's source code again and that seems to confirm > what you are reading in the RFC: Leaving the service name away makes > seems to violate the RFC, but pppd still accepts those configurations. > >> Even if it is, if this is breaking established userspace expectations, >> we should look into it. Ethernet specifies a minimum payload size of >> 46 on the wire, but perhaps that is handled with padding, so that >> 0 length should be valid within the stack. Also, there may be other >> valid uses of 0 length payload on top of link layers that are not Ethernet. > Good catch. I would also like to note that the documentation for > "hard_header_len" describes it as "Hardware header length". When the > purpose of this field we should check whether the documentation should > be updated to "Minimum hardware header length" -> that would mean the > condition has to be a "len < hard_header_len" instead of a "len <= > hard_header_len" (as it is now). > > PS: I have also added the pppd maintainer (Paul Mackerras) to this > thread because I think he should know about this issue (and he can > probably provide more details if required). > As a quick summary for him: linux >= 3.19 rejects PADI packets when > no service name is configured. Any news on this? Users are complaining about this regression: https://dev.openwrt.org/ticket/20707 - Felix -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net 1/2] packet: do skb_probe_transport_header when we actually have data
On Fri, 2015-11-06 at 22:02 +0100, Daniel Borkmann wrote:
> In tpacket_fill_skb() commit c1aad275b029 ("packet: set transport
> header before doing xmit") and later on 40893fd0fd4e ("net: switch
> to use skb_probe_transport_header()") was probing for a transport
> header on the skb from a ring buffer slot, but at a time, where
> the skb has _not even_ been filled with data yet. So that call into
> the flow dissector is pretty useless. Lets do it after we've set
> up the skb frags.
>
> Fixes: c1aad275b029 ("packet: set transport header before doing xmit")
> Reported-by: Eric Dumazet
> Cc: Jason Wang
> + if (!packet_use_direct_xmit(po))
> + skb_probe_transport_header(skb, 0);
> +
Thanks Daniel for working on this.
The if (!packet_use_direct_xmit(po)) test looks dubious.
Setting transport header has nothing to do with bypassing qdisc ?
This might lead to hard to debug problems, for drivers expecting
transport header being set ?
Maybe this needs a special socket flag, but this does not seem worth the pain.
(This would be different of course if trafgen was not defaulting to qdisc
bypass)
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re:netdev在?“(AD)
netdev
欢迎加入爱奇艺vip分享QQ群：5650047 每天发放好几波爱奇艺vip会员，看蜀山战纪，灵魂摆渡2等热门大片不要钱！限时开放！验证码511
蚊媒介的病毒性发热？我会好起来，安得南征驰捷报。不答天女问？予欲无言！深水稻”云路邈且深！后乐园：灰褐羽蛾！复睹出师篇，苗圃生产成本审计？胡啼番语两玲珑：中央台。敏捷生物光学远望镜；润心阁，爱情的尽头；公元前四七五二年：苍山糙苏原变种：杞梓里镇“津利华名！富氧区，妥善处理好”脚间池“缨鞘宽腹叶蜂“符头“低产林改造；亚尖叶锥！中等蓝宝石？细齿小厚壳水蚤，宋溪头：土千年健”N�r��yb�X��ǧv�^�){.n�+���z�^�)w* jg��� �ݢj/���z�ޖ��2�ޙ&�)ߡ�a���� �G���h��j:+v���w��٥
Re: [PATCH] man: Syntax and warning fixes
2015-11-07 7:44 GMT-02:00 Ville Skyttä : > --- > man/man8/tc-bpf.8 | 2 +- > man/man8/tipc-bearer.8| 4 ++-- > man/man8/tipc-link.8 | 6 +++--- > man/man8/tipc-media.8 | 4 ++-- > man/man8/tipc-nametable.8 | 4 ++-- > man/man8/tipc-node.8 | 4 ++-- > man/man8/tipc-socket.8| 4 ++-- > 7 files changed, 14 insertions(+), 14 deletions(-) > > diff --git a/man/man8/tc-bpf.8 b/man/man8/tc-bpf.8 > index 2c02ab2..f5201d3 100644 > --- a/man/man8/tc-bpf.8 > +++ b/man/man8/tc-bpf.8 > @@ -844,7 +844,7 @@ result in the default classid: > Basically, such a minimal generator is equivalent to: Signed-off-by and description ? Albino -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] man: Syntax and warning fixes
On Sat, Nov 7, 2015 at 11:47 AM, Albino B Neto wrote: > 2015-11-07 7:44 GMT-02:00 Ville Skyttä : >> --- >> man/man8/tc-bpf.8 | 2 +- >> man/man8/tipc-bearer.8| 4 ++-- >> man/man8/tipc-link.8 | 6 +++--- >> man/man8/tipc-media.8 | 4 ++-- >> man/man8/tipc-nametable.8 | 4 ++-- >> man/man8/tipc-node.8 | 4 ++-- >> man/man8/tipc-socket.8| 4 ++-- >> 7 files changed, 14 insertions(+), 14 deletions(-) >> >> diff --git a/man/man8/tc-bpf.8 b/man/man8/tc-bpf.8 >> index 2c02ab2..f5201d3 100644 >> --- a/man/man8/tc-bpf.8 >> +++ b/man/man8/tc-bpf.8 >> @@ -844,7 +844,7 @@ result in the default classid: >> Basically, such a minimal generator is equivalent to: > > Signed-off-by and description ? Superseding patches sent separately. I suggest documenting the requirement for Signed-off-by somewhere (README.devel?); git log shows lots of commits without it, especially a bunch of man page related ones about a week ago. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] man: Spelling fixes
Signed-off-by: Ville Skyttä --- man/man8/bridge.8 | 2 +- man/man8/ifcfg.8 | 2 +- man/man8/lnstat.8 | 2 +- man/man8/tc-bpf.8 | 2 +- man/man8/tc-cbq-details.8 | 2 +- man/man8/tc-mqprio.8 | 2 +- man/man8/tc.8 | 2 +- 7 files changed, 7 insertions(+), 7 deletions(-) diff --git a/man/man8/bridge.8 b/man/man8/bridge.8 index 222a438..deccb1c 100644 --- a/man/man8/bridge.8 +++ b/man/man8/bridge.8 @@ -237,7 +237,7 @@ state the port for list for STP BPDUs and drop all other traffic. .B 2 - STP LEARNING state. Only valid if STP is enabled on the bridge. In this state the port will accept traffic only for the purpose of updating MAC -adress tables. +address tables. .sp .B 3 diff --git a/man/man8/ifcfg.8 b/man/man8/ifcfg.8 index 79033bd..1a3786c 100644 --- a/man/man8/ifcfg.8 +++ b/man/man8/ifcfg.8 @@ -1,6 +1,6 @@ .TH IFCFG 8 "September 24 2009" "iproute2" "Linux" .SH NAME -ifcfg \- simplistic script which replaces ifconfig IP managment +ifcfg \- simplistic script which replaces ifconfig IP management .SH SYNOPSIS .ad l .in +8 diff --git a/man/man8/lnstat.8 b/man/man8/lnstat.8 index 69fe876..acd5f4a 100644 --- a/man/man8/lnstat.8 +++ b/man/man8/lnstat.8 @@ -172,7 +172,7 @@ Number of dropped conntrack entries to make room for new ones, if maximum table size was reached. .sp .B icmp_error -Number of packets wich could not be tracked due to error situation. This is a +Number of packets which could not be tracked due to error situation. This is a subset of \fBinvalid\fP. .sp .B expect_new diff --git a/man/man8/tc-bpf.8 b/man/man8/tc-bpf.8 index f5201d3..c8d5c5f 100644 --- a/man/man8/tc-bpf.8 +++ b/man/man8/tc-bpf.8 @@ -394,7 +394,7 @@ socket, and spawning an application such as \&. This approach's advantage is that tc will place the file descriptors into the environment and thus make them available just like stdin, stdout, stderr file descriptors, meaning, in case user applications run from within -this fd-owner shell, they can terminate and restart without loosing eBPF +this fd-owner shell, they can terminate and restart without losing eBPF maps file descriptors. Example invocation with the previous classifier and action mixture: diff --git a/man/man8/tc-cbq-details.8 b/man/man8/tc-cbq-details.8 index ddaf3ca..86353b5 100644 --- a/man/man8/tc-cbq-details.8 +++ b/man/man8/tc-cbq-details.8 @@ -197,7 +197,7 @@ priority yielded a class, enter the fallback algorithm. The fallback algorithm resides outside of the loop and is as follows. .TP (i) -Consult the defmap of the class at which the jump to fallback occured. If +Consult the defmap of the class at which the jump to fallback occurred. If the defmap contains a class for the .B priority diff --git a/man/man8/tc-mqprio.8 b/man/man8/tc-mqprio.8 index da3bf08..0e1d305 100644 --- a/man/man8/tc-mqprio.8 +++ b/man/man8/tc-mqprio.8 @@ -85,7 +85,7 @@ belong to an application. See kernel and cgroup documentation for details. .SH QDISC PARAMETERS .TP num_tc -Number of traffic classes to use upto 16 classes supported. +Number of traffic classes to use. Up to 16 classes supported. .TP map diff --git a/man/man8/tc.8 b/man/man8/tc.8 index 700b960..7a1090b 100644 --- a/man/man8/tc.8 +++ b/man/man8/tc.8 @@ -609,7 +609,7 @@ to .TP .BR "\-cf" , " \-conf " -specifies path to the config file. This option is used in conjuction with other options (e.g. +specifies path to the config file. This option is used in conjunction with other options (e.g. .BR -nm ")." .SH FORMAT -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] man: Syntax and warning fixes
Fix syntax issues and warnings highlighted by `man --warnings=w' from man-db 2.7.1. Signed-off-by: Ville Skyttä --- man/man8/tc-bpf.8 | 2 +- man/man8/tipc-bearer.8| 4 ++-- man/man8/tipc-link.8 | 6 +++--- man/man8/tipc-media.8 | 4 ++-- man/man8/tipc-nametable.8 | 4 ++-- man/man8/tipc-node.8 | 4 ++-- man/man8/tipc-socket.8| 4 ++-- 7 files changed, 14 insertions(+), 14 deletions(-) diff --git a/man/man8/tc-bpf.8 b/man/man8/tc-bpf.8 index 2c02ab2..f5201d3 100644 --- a/man/man8/tc-bpf.8 +++ b/man/man8/tc-bpf.8 @@ -844,7 +844,7 @@ result in the default classid: Basically, such a minimal generator is equivalent to: .in +4n -.B tcpdump -iem1 -ddd 'tcp[tcpflags] & tcp-syn != 0' | tr '\\n' ',' > /var/bpf/tcp-syn +.B tcpdump -iem1 -ddd 'tcp[tcpflags] & tcp-syn != 0' | tr 'n' ',' > /var/bpf/tcp-syn .in Since diff --git a/man/man8/tipc-bearer.8 b/man/man8/tipc-bearer.8 index f59c39d..50a1ed2 100644 --- a/man/man8/tipc-bearer.8 +++ b/man/man8/tipc-bearer.8 @@ -1,7 +1,7 @@ .TH TIPC-BEARER 8 "02 Jun 2015" "iproute2" "Linux" -./ For consistency, please keep padding right aligned. -./ For example '.B "foo " bar' and not '.B foo " bar"' +.\" For consistency, please keep padding right aligned. +.\" For example '.B "foo " bar' and not '.B foo " bar"' .SH NAME tipc-bearer \- show or modify TIPC bearers diff --git a/man/man8/tipc-link.8 b/man/man8/tipc-link.8 index 899b882..3be8c9a 100644 --- a/man/man8/tipc-link.8 +++ b/man/man8/tipc-link.8 @@ -1,7 +1,7 @@ .TH TIPC-LINK 8 "02 Jun 2015" "iproute2" "Linux" -./ For consistency, please keep padding right aligned. -./ For example '.B "foo " bar' and not '.B foo " bar"' +.\" For consistency, please keep padding right aligned. +.\" For example '.B "foo " bar' and not '.B foo " bar"' .SH NAME tipc-link \- show links or modify link properties @@ -33,7 +33,7 @@ tipc-link \- show links or modify link properties .I LINK .RB "] | " "reset .BI "link " "LINK " -.R } +} .ti -8 .B tipc link list diff --git a/man/man8/tipc-media.8 b/man/man8/tipc-media.8 index 7f94efe..6c6e2b1 100644 --- a/man/man8/tipc-media.8 +++ b/man/man8/tipc-media.8 @@ -1,7 +1,7 @@ .TH TIPC-MEDIA 8 "02 Jun 2015" "iproute2" "Linux" -./ For consistency, please keep padding right aligned. -./ For example '.B "foo " bar' and not '.B foo " bar"' +.\" For consistency, please keep padding right aligned. +.\" For example '.B "foo " bar' and not '.B foo " bar"' .SH NAME tipc-media \- list or modify media properties diff --git a/man/man8/tipc-nametable.8 b/man/man8/tipc-nametable.8 index c8d573f..d3397f9 100644 --- a/man/man8/tipc-nametable.8 +++ b/man/man8/tipc-nametable.8 @@ -1,7 +1,7 @@ .TH TIPC-NAMETABLE 8 "02 Jun 2015" "iproute2" "Linux" -./ For consistency, please keep padding right aligned. -./ For example '.B "foo " bar' and not '.B foo " bar"' +.\" For consistency, please keep padding right aligned. +.\" For example '.B "foo " bar' and not '.B foo " bar"' .SH NAME tipc-nametable \- show TIPC nametable diff --git a/man/man8/tipc-node.8 b/man/man8/tipc-node.8 index 66418b3..ef32ec7 100644 --- a/man/man8/tipc-node.8 +++ b/man/man8/tipc-node.8 @@ -1,7 +1,7 @@ .TH TIPC-NODE 8 "02 Jun 2015" "iproute2" "Linux" -./ For consistency, please keep padding right aligned. -./ For example '.B "foo " bar' and not '.B foo " bar"' +.\" For consistency, please keep padding right aligned. +.\" For example '.B "foo " bar' and not '.B foo " bar"' .SH NAME tipc-node \- modify and show local node parameters or list peer nodes diff --git a/man/man8/tipc-socket.8 b/man/man8/tipc-socket.8 index af18e35..23ec1e5 100644 --- a/man/man8/tipc-socket.8 +++ b/man/man8/tipc-socket.8 @@ -1,7 +1,7 @@ .TH TIPC-SOCKET 8 "02 Jun 2015" "iproute2" "Linux" -./ For consistency, please keep padding right aligned. -./ For example '.B "foo " bar' and not '.B foo " bar"' +.\" For consistency, please keep padding right aligned. +.\" For example '.B "foo " bar' and not '.B foo " bar"' .SH NAME tipc-socket \- show TIPC socket (port) information -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] man: Spelling fixes
--- man/man8/bridge.8 | 2 +- man/man8/ifcfg.8 | 2 +- man/man8/lnstat.8 | 2 +- man/man8/tc-bpf.8 | 2 +- man/man8/tc-cbq-details.8 | 2 +- man/man8/tc-mqprio.8 | 2 +- man/man8/tc.8 | 2 +- 7 files changed, 7 insertions(+), 7 deletions(-) diff --git a/man/man8/bridge.8 b/man/man8/bridge.8 index 222a438..deccb1c 100644 --- a/man/man8/bridge.8 +++ b/man/man8/bridge.8 @@ -237,7 +237,7 @@ state the port for list for STP BPDUs and drop all other traffic. .B 2 - STP LEARNING state. Only valid if STP is enabled on the bridge. In this state the port will accept traffic only for the purpose of updating MAC -adress tables. +address tables. .sp .B 3 diff --git a/man/man8/ifcfg.8 b/man/man8/ifcfg.8 index 79033bd..1a3786c 100644 --- a/man/man8/ifcfg.8 +++ b/man/man8/ifcfg.8 @@ -1,6 +1,6 @@ .TH IFCFG 8 "September 24 2009" "iproute2" "Linux" .SH NAME -ifcfg \- simplistic script which replaces ifconfig IP managment +ifcfg \- simplistic script which replaces ifconfig IP management .SH SYNOPSIS .ad l .in +8 diff --git a/man/man8/lnstat.8 b/man/man8/lnstat.8 index 69fe876..acd5f4a 100644 --- a/man/man8/lnstat.8 +++ b/man/man8/lnstat.8 @@ -172,7 +172,7 @@ Number of dropped conntrack entries to make room for new ones, if maximum table size was reached. .sp .B icmp_error -Number of packets wich could not be tracked due to error situation. This is a +Number of packets which could not be tracked due to error situation. This is a subset of \fBinvalid\fP. .sp .B expect_new diff --git a/man/man8/tc-bpf.8 b/man/man8/tc-bpf.8 index f5201d3..c8d5c5f 100644 --- a/man/man8/tc-bpf.8 +++ b/man/man8/tc-bpf.8 @@ -394,7 +394,7 @@ socket, and spawning an application such as \&. This approach's advantage is that tc will place the file descriptors into the environment and thus make them available just like stdin, stdout, stderr file descriptors, meaning, in case user applications run from within -this fd-owner shell, they can terminate and restart without loosing eBPF +this fd-owner shell, they can terminate and restart without losing eBPF maps file descriptors. Example invocation with the previous classifier and action mixture: diff --git a/man/man8/tc-cbq-details.8 b/man/man8/tc-cbq-details.8 index ddaf3ca..86353b5 100644 --- a/man/man8/tc-cbq-details.8 +++ b/man/man8/tc-cbq-details.8 @@ -197,7 +197,7 @@ priority yielded a class, enter the fallback algorithm. The fallback algorithm resides outside of the loop and is as follows. .TP (i) -Consult the defmap of the class at which the jump to fallback occured. If +Consult the defmap of the class at which the jump to fallback occurred. If the defmap contains a class for the .B priority diff --git a/man/man8/tc-mqprio.8 b/man/man8/tc-mqprio.8 index da3bf08..0e1d305 100644 --- a/man/man8/tc-mqprio.8 +++ b/man/man8/tc-mqprio.8 @@ -85,7 +85,7 @@ belong to an application. See kernel and cgroup documentation for details. .SH QDISC PARAMETERS .TP num_tc -Number of traffic classes to use upto 16 classes supported. +Number of traffic classes to use. Up to 16 classes supported. .TP map diff --git a/man/man8/tc.8 b/man/man8/tc.8 index 700b960..7a1090b 100644 --- a/man/man8/tc.8 +++ b/man/man8/tc.8 @@ -609,7 +609,7 @@ to .TP .BR "\-cf" , " \-conf " -specifies path to the config file. This option is used in conjuction with other options (e.g. +specifies path to the config file. This option is used in conjunction with other options (e.g. .BR -nm ")." .SH FORMAT -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] man: Syntax and warning fixes
--- man/man8/tc-bpf.8 | 2 +- man/man8/tipc-bearer.8| 4 ++-- man/man8/tipc-link.8 | 6 +++--- man/man8/tipc-media.8 | 4 ++-- man/man8/tipc-nametable.8 | 4 ++-- man/man8/tipc-node.8 | 4 ++-- man/man8/tipc-socket.8| 4 ++-- 7 files changed, 14 insertions(+), 14 deletions(-) diff --git a/man/man8/tc-bpf.8 b/man/man8/tc-bpf.8 index 2c02ab2..f5201d3 100644 --- a/man/man8/tc-bpf.8 +++ b/man/man8/tc-bpf.8 @@ -844,7 +844,7 @@ result in the default classid: Basically, such a minimal generator is equivalent to: .in +4n -.B tcpdump -iem1 -ddd 'tcp[tcpflags] & tcp-syn != 0' | tr '\\n' ',' > /var/bpf/tcp-syn +.B tcpdump -iem1 -ddd 'tcp[tcpflags] & tcp-syn != 0' | tr 'n' ',' > /var/bpf/tcp-syn .in Since diff --git a/man/man8/tipc-bearer.8 b/man/man8/tipc-bearer.8 index f59c39d..50a1ed2 100644 --- a/man/man8/tipc-bearer.8 +++ b/man/man8/tipc-bearer.8 @@ -1,7 +1,7 @@ .TH TIPC-BEARER 8 "02 Jun 2015" "iproute2" "Linux" -./ For consistency, please keep padding right aligned. -./ For example '.B "foo " bar' and not '.B foo " bar"' +.\" For consistency, please keep padding right aligned. +.\" For example '.B "foo " bar' and not '.B foo " bar"' .SH NAME tipc-bearer \- show or modify TIPC bearers diff --git a/man/man8/tipc-link.8 b/man/man8/tipc-link.8 index 899b882..3be8c9a 100644 --- a/man/man8/tipc-link.8 +++ b/man/man8/tipc-link.8 @@ -1,7 +1,7 @@ .TH TIPC-LINK 8 "02 Jun 2015" "iproute2" "Linux" -./ For consistency, please keep padding right aligned. -./ For example '.B "foo " bar' and not '.B foo " bar"' +.\" For consistency, please keep padding right aligned. +.\" For example '.B "foo " bar' and not '.B foo " bar"' .SH NAME tipc-link \- show links or modify link properties @@ -33,7 +33,7 @@ tipc-link \- show links or modify link properties .I LINK .RB "] | " "reset .BI "link " "LINK " -.R } +} .ti -8 .B tipc link list diff --git a/man/man8/tipc-media.8 b/man/man8/tipc-media.8 index 7f94efe..6c6e2b1 100644 --- a/man/man8/tipc-media.8 +++ b/man/man8/tipc-media.8 @@ -1,7 +1,7 @@ .TH TIPC-MEDIA 8 "02 Jun 2015" "iproute2" "Linux" -./ For consistency, please keep padding right aligned. -./ For example '.B "foo " bar' and not '.B foo " bar"' +.\" For consistency, please keep padding right aligned. +.\" For example '.B "foo " bar' and not '.B foo " bar"' .SH NAME tipc-media \- list or modify media properties diff --git a/man/man8/tipc-nametable.8 b/man/man8/tipc-nametable.8 index c8d573f..d3397f9 100644 --- a/man/man8/tipc-nametable.8 +++ b/man/man8/tipc-nametable.8 @@ -1,7 +1,7 @@ .TH TIPC-NAMETABLE 8 "02 Jun 2015" "iproute2" "Linux" -./ For consistency, please keep padding right aligned. -./ For example '.B "foo " bar' and not '.B foo " bar"' +.\" For consistency, please keep padding right aligned. +.\" For example '.B "foo " bar' and not '.B foo " bar"' .SH NAME tipc-nametable \- show TIPC nametable diff --git a/man/man8/tipc-node.8 b/man/man8/tipc-node.8 index 66418b3..ef32ec7 100644 --- a/man/man8/tipc-node.8 +++ b/man/man8/tipc-node.8 @@ -1,7 +1,7 @@ .TH TIPC-NODE 8 "02 Jun 2015" "iproute2" "Linux" -./ For consistency, please keep padding right aligned. -./ For example '.B "foo " bar' and not '.B foo " bar"' +.\" For consistency, please keep padding right aligned. +.\" For example '.B "foo " bar' and not '.B foo " bar"' .SH NAME tipc-node \- modify and show local node parameters or list peer nodes diff --git a/man/man8/tipc-socket.8 b/man/man8/tipc-socket.8 index af18e35..23ec1e5 100644 --- a/man/man8/tipc-socket.8 +++ b/man/man8/tipc-socket.8 @@ -1,7 +1,7 @@ .TH TIPC-SOCKET 8 "02 Jun 2015" "iproute2" "Linux" -./ For consistency, please keep padding right aligned. -./ For example '.B "foo " bar' and not '.B foo " bar"' +.\" For consistency, please keep padding right aligned. +.\" For example '.B "foo " bar' and not '.B foo " bar"' .SH NAME tipc-socket \- show TIPC socket (port) information -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
