Does lox interfaces support looping ethernet traffic?
Hi, I'm trying to send traffic to myself (server and client on the same machine) using rdma connection management. I'm failing. What I saw is that in netstat -rn all traffic with my IP destination go through lo0, and therefore the rtalloc1 function (in file route.c) returns lo0. My problem is when using arpresolve (in file if_ether.c) afterwards, in order to retrieve the MAC, the arpresolve fails for lo0 (I can see also that it doesn't have MAC addr). So my question is what should I do in order to be able to send traffic to myself using the functions rtalloc1 and arpresolve? Thanks, Shany Michaely | SW Engineer ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Fragment questions
Hello,
Please find attached a proposal using atomic_fetchadd.
Best Regards,
Emeric
- Mail original -
De: "Adrian Chadd"
À: "Hans Petter Selasky"
Cc: "Emeric POUPON" , "freebsd-net"
Envoyé: Vendredi 20 Mars 2015 20:04:44
Objet: Re: Fragment questions
On 20 March 2015 at 11:56, Hans Petter Selasky wrote:
> On 03/20/15 19:02, Adrian Chadd wrote:
>>
>> On 20 March 2015 at 10:58, Hans Petter Selasky wrote:
>>>
>>> On 03/20/15 14:31, Emeric POUPON wrote:
- in the ip_newid macro, we do "htons(V_ip_id++))" if we do not use
randomized id.
>>>
>>>
In multi core systems, we may emit successive packets with the same id.
>>>
>>>
>>> Will using a mutex or an atomic macro fix this issue when incrementing
>>> the
>>> V_ip_id ?
>>
>>
>> It will, but it'll ping-pong between multiple cores and slow things
>> down at high pps.
>>
>
> Hi,
>
> Maybe we can have the V_ip_id per CPU and use the lower 8-bits as random CPU
> core number?
Hm, someone with more cycles to spend on analysing the repercussions
from this should investigate it.
I think in the short term using an atomic is fine, as it's no worse
than what is currently there. But as we get more PPS unlocked and
happening we may need to fix it.
-adrian
--- sys/netinet/ip_var.h.orig 2015-03-23 17:57:40.601072200 +0100
+++ sys/netinet/ip_var.h 2015-03-23 17:58:31.093715177 +0100
@@ -174,7 +174,7 @@ struct inpcb;
struct route;
struct sockopt;
-VNET_DECLARE(u_short, ip_id); /* ip packet ctr, for ids */
+VNET_DECLARE(u_int32_t, ip_id); /* ip packet ctr, for ids */
VNET_DECLARE(int, ip_defttl); /* default IP ttl */
VNET_DECLARE(int, ipforwarding); /* ip forwarding */
#ifdef IPSTEALTH
@@ -306,7 +306,7 @@ extern int (*ip_dn_io_ptr)(struct mbuf *
VNET_DECLARE(int, ip_do_randomid);
#define V_ip_do_randomid VNET(ip_do_randomid)
#define ip_newid() ((V_ip_do_randomid != 0) ? ip_randomid() : \
- htons(V_ip_id++))
+ htons(atomic_fetchadd_32(&V_ip_id, 1) & 0x))
#endif /* _KERNEL */
--- sys/netinet/ip_output.c.orig 2015-03-23 17:57:46.514498846 +0100
+++ sys/netinet/ip_output.c 2015-03-23 17:58:52.124426760 +0100
@@ -91,7 +91,7 @@ __FBSDID("$FreeBSD: head/sys/netinet/ip_
#include
-VNET_DEFINE(u_short, ip_id);
+VNET_DEFINE(u_int32_t, ip_id);
#ifdef MBUF_STRESS_TEST
static int mbuf_frag_size = 0;
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
siftr buildkernel failure?
Anyone else seeing this on -current right now? /usr/home/elars/src/sys/modules/siftr/../../netinet/siftr.c:493:7: error: data argument not used by format string [-Werror,-Wformat-extra-args] pkt_node->flowid, ^ Lars signature.asc Description: Message signed with OpenPGP using GPGMail
[Differential] [Accepted] D1777: Associated fix for arp/nd6 timer usage.
sbruno accepted this revision. This revision is now accepted and ready to land. REVISION DETAIL https://reviews.freebsd.org/D1777 To: rrs, imp, gnn, rwatson, lstewart, kostikbel, adrian, jhb, bz, sbruno Cc: ae, bz, emaste, hiren, julian, hselasky, freebsd-net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] [Updated] D1777: Associated fix for arp/nd6 timer usage.
sbruno added a comment. Randall: Do you want to close this review as committed? The commit hook doesn't seem to have fired to close this when comitted at svn r278472 REVISION DETAIL https://reviews.freebsd.org/D1777 To: rrs, imp, gnn, rwatson, lstewart, kostikbel, adrian, jhb, bz, sbruno Cc: ae, bz, emaste, hiren, julian, hselasky, freebsd-net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] [Accepted] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests).
sbruno accepted this revision. sbruno added a comment. This revision is now accepted and ready to land. Randall: I think this needs to be manually closed as the svn commit hook didn't fire when r278469 hit the tree. REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, imp, adrian, hselasky, sbruno Cc: julian, hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: siftr buildkernel failure?
On 03/24/15 07:49, Eggert, Lars wrote: > Anyone else seeing this on -current right now? > > /usr/home/elars/src/sys/modules/siftr/../../netinet/siftr.c:493:7: error: > data argument not used by format string [-Werror,-Wformat-extra-args] > pkt_node->flowid, > ^ I didn't look at enough context when reviewing r280233 and missed the bug. Should be fixed in r280441. Thanks for the report and apologies for the hassle. Cheers, Lawrence ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: siftr buildkernel failure?
On 03/24/15 at 10:09P, Lawrence Stewart wrote: > On 03/24/15 07:49, Eggert, Lars wrote: > > Anyone else seeing this on -current right now? > > > > /usr/home/elars/src/sys/modules/siftr/../../netinet/siftr.c:493:7: error: > > data argument not used by format string [-Werror,-Wformat-extra-args] > > pkt_node->flowid, > > ^ > > I didn't look at enough context when reviewing r280233 and missed the > bug. Should be fixed in r280441. Thanks for the report and apologies for > the hassle. Apologies for missing the v6 part. Thanks Lawrence for the quick fix. Hiren pgpZ5buJLgGDn.pgp Description: PGP signature
Re: Full 32bit flowid from igb(4)
On 03/23/15 at 04:58P, Jack Vogel wrote: > I think that line was there at one time outside the RSS define, I believe this was added by Adrian as part of RSS work and was not there before. I may be wrong. > I'd have to > take a look at > the code a bit more, or maybe Eric will I'll wait for the comments. Cheers, Hiren > > Jack > > > On Mon, Mar 23, 2015 at 4:42 PM, hiren panchasara < > hi...@strugglingcoder.info> wrote: > > > Correcting Eric's email and subject line. > > > > On 03/23/15 at 04:39P, hiren panchasara wrote: > > > sco...@freebsd.org > > > Bcc: > > > Subject: Full 32bit flowid from igb(4) [was: Re: Unbalanced LACP link] > > > Reply-To: > > > In-Reply-To: <20150319175145.gh53...@strugglingcoder.info> > > > > > > On 03/19/15 at 10:51P, hiren panchasara wrote: > > > > On 03/17/15 at 12:34P, Adrian Chadd wrote: > > > > > On 17 March 2015 at 11:33, Jason Wolfe wrote: > > > > > > On Mon, Mar 16, 2015 at 2:43 AM, Hans Petter Selasky < > > h...@selasky.org> wrote: > > > > > >> On 03/16/15 10:37, Vitalii Duk wrote: > > > > > >>> > > > > > >>> I've changed use_flowid to 0 and it helped! But isn't it setting > > > > > >>> significant? In a description it says "Shift flowid bits to > > prevent > > > > > >>> multiqueue collisions". > > > > > >> > > > > > >> > > > > > >> Hi, > > > > > >> > > > > > >> Maybe your ethernet hardware is not properly setting the m_flowid > > ... > > > > > >> > > > > > >> --HPS > > > > > >> > > > > > > > > > > > > Flip use_flowid back to 1 and try setting > > > > > > net.link.lagg.default_flowid_shift / net.link.lagg.X.flowid_shift > > to 0 > > > > > > as Hiren suggested. r260179 added this shift, which has caused us > > > > > > balancing issues with the i350/igb. > > > > > > > > > > > > https://svnweb.freebsd.org/base?view=revision&revision=260179 > > > > > > > > > > > > Based on Adrian's comment about igb/ixgbe not setting the 'full > > > > > > flowid' under normal conditions, does that mean this shift should > > be 0 > > > > > > by default to ensure we don't break balancing for devices that only > > > > > > set the CPU/MSIX queue? > > > > > > > > > > Or we can just see if there's anything wrong with putting the full 32 > > > > > bit RSS flowid in received packets that have them. > > > > > > > > It'd be nice to have but for now I am proposing following to fix a > > known > > > > broken case because of an optimization: > > > > https://reviews.freebsd.org/D2098 > > > > > > Turns out, setting flowid_shift to 0 is not the correct solution. Please > > > look at the review above for more details. > > > > > > Looking at the code, we have a way to get full flowid but it's hidden > > > under "ifdef RSS": > > > rxr->fmp->m_pkthdr.flowid = le32toh(cur->wb.lower.hi_dword.rss); > > > > > > Using just this line gives me good hash on I350 igb(4) chipset that we > > > have. > > > > > > Is it possible to expose this outside RSS? Would this break other > > > things/chips? > > > > > > Cheers, > > > Hiren > > > > > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" pgpUCFeqqStJr.pgp Description: PGP signature
Re: Full 32bit flowid from igb(4)
Hi, The main reason I didn't add it outside of RSS is that I didn't want to impact the behaviour that was there before. Before, it wasn't using the flowid - only the msix/queue id. I read the intel datasheets about that particular field - I'm pretty sure that by default we'll only see RSS hashed packets for IPv4/IPv6, however non v4/v6 packets won't have a flowid. There are also cases of the flow director or some hardware checksum config using the same field as the flowid. The /full/ solution would very carefully check the return status and ensure what's in the flowid field is a flowid. The "sometimes it may have a flowid, sometimes it won't" problem isn't so bad with kernel RSS enabled - it'll just software hash it. -adrian ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
