Re: CFT: major update to if_ure
On Sun, Jul 26, 2020 at 7:13 AM John-Mark Gurney wrote: > Hello, > > I'd like people who have ure (RealTek) based USB devices to test > review D25809[0]. > > This update adds support for: > - HW VLAN tagging > - HW checksum offload for IPv4 and IPv6 > - tx and rx aggreegation (for full gige speeds) > - multiple transactions > > In my testing, I am able to get 900-950Mbps depending upon > TCP or UDP, which is a significant improvement over the previous > 91Mbps (~8kint/sec*1500bytes/packet*1packet/int). > Does performance improve for if_ure device on USB2? I will try to test it in a couple of days on NanoPI R1 and R1S boards. thanks, Ganbold > > Thanks. > > [0] https://reviews.freebsd.org/D25809 > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
CFT: major update to if_ure
Hello, I'd like people who have ure (RealTek) based USB devices to test review D25809[0]. This update adds support for: - HW VLAN tagging - HW checksum offload for IPv4 and IPv6 - tx and rx aggreegation (for full gige speeds) - multiple transactions In my testing, I am able to get 900-950Mbps depending upon TCP or UDP, which is a significant improvement over the previous 91Mbps (~8kint/sec*1500bytes/packet*1packet/int). Thanks. [0] https://reviews.freebsd.org/D25809 -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: somewhat reproducable vimage panic
John-Mark Gurney wrote this message on Thu, Jul 23, 2020 at 16:49 -0700: > Kristof Provost wrote this message on Thu, Jul 23, 2020 at 11:02 +0200: > > On 23 Jul 2020, at 11:00, Bjoern A. Zeeb wrote: > > > On 23 Jul 2020, at 8:09, Kristof Provost wrote: > > > > > >> On 23 Jul 2020, at 9:19, Kristof Provost wrote: > > >>> On 23 Jul 2020, at 0:15, John-Mark Gurney wrote: > > So, it's pretty easy to trigger, just attach a couple USB ethernet > > adapters, in my case, they were ure, but likely any two spare > > ethernet > > interfaces will work, and wire them back to back.. > > > > >>> I???ve been able to trigger it using epair as well: > > >>> > > >>> `sudo sh testinterfaces.txt epair0a epair0b` > > >>> > > >>> I did have to comment out the waitcarrier() check. > > >>> > > >> I???ve done a little bit of digging, and I think I???m starting to > > >> see how this breaks. > > >> > > >> This always affects the jailed vlan interfaces. They???re getting > > >> deleted, but the ifp doesn???t go away just yet because it???s still > > >> in use by the multicast code. > > >> The multicast code does its cleanup in task queues, > > > > > > Wow, did I miss that back then? Did I review a change and not notice? > > > Sorry if that was the case. > > > > > > Vnet teardown is blocking and forceful. > > > Doing deferred cleanup work isn???t a good idea at all. > > > I think that is the real problem here. > > > > > > I???d rather have us fix this than putting more bandaids into the > > > code. > > > > > Yeah, agreed. I think hselasky has a better fix: > > https://reviews.freebsd.org/D24914 > > > > I just saw his e-mail in a different thread. > > I'm testing out this patch now, and let people know how it goes.. It'll > be nice to not have to worry about these panics.. So far so good... I am getting these on occasion: in6_purgeaddr: err=65, destination address delete failed But that's more that the patch prevented a panic. The other issue that I'm now seeing is that because we don't forcefully clear out the multicast task, it can take a good 20+ seconds from the time a jail is destroyed to the interface appearing again in vnet0. Pretty sure this is related to the dmesg from above... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: nightly snapshot for CURRENT ?
On Fri, 24 Jul 2020 22:28:39 + Glen Barber wrote: > On Sat, Jul 25, 2020 at 12:14:52AM +0200, Emmanuel Vadot wrote: > > On Fri, 24 Jul 2020 22:06:07 + > > Glen Barber wrote: > > > > > On Fri, Jul 24, 2020 at 10:31:35PM +0200, Emmanuel Vadot wrote: > > > > On Tue, 9 Jun 2020 22:04:07 +0200 > > > > Emmanuel Vadot wrote: > > > > > > > > > On Tue, 9 Jun 2020 19:56:30 + > > > > > Glen Barber wrote: > > > > > > > > > > > On Tue, Jun 09, 2020 at 09:47:56PM +0200, Emmanuel Vadot wrote: > > > > > > > > > > > > > > Hello all, > > > > > > > > > > > > > > I've just hit again something that I've hit (and probably others > > > > > > > too) > > > > > > > often. > > > > > > > If a change in base break some ports and it's snapshoted in the > > > > > > > txz > > > > > > > available at download.freebsd.org, you need to wait a week for > > > > > > > the next > > > > > > > tarball to be available. > > > > > > > Since poudriere uses the tarball when you setup a jail it means > > > > > > > that > > > > > > > the only solution you have is to recreate your jail by building > > > > > > > it, and > > > > > > > since building world nowdays is very expensive that delay your > > > > > > > work too > > > > > > > much. > > > > > > > Would it be possible to generate the tarballs every day instead > > > > > > > of > > > > > > > every week ? At least for tier-1 arches. > > > > > > > > > > > > > > > > > > > Let's revisit this sometime next week after 11.4 is out. > > > > > > > > > > > > Glen > > > > > > > > > > > > > > > > Sure, works for me. > > > > > > > > > > Thanks, > > > > > > > > > > > > > Ping ? > > > > > > > > > > I thought the artifacts from the jenkins builder for CI were sufficient. > > > > > > Glen > > > > > > > Yes and no, > > > > I can add something to poudriere for getting the tarballs from the CI > > artifacts but that won't be by default. > > > > To be honest, that would be the preferred route, since updating the > various *.txz distribution sets would break things like bootonly.iso, > mini-memstick.img, and so on. Why would it break things ? > In other words, we already have a system in place that generates these > archive files, so I personally see no need to disrupt the "official" > snapshot build process to appease a subset of the user base while > unnecessarily adding a pain point for the rest. > > Glen > If only the sets are generated each day I don't see how it can cause a pain to anyone. -- Emmanuel Vadot ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
