trpt(8) to be decomissioned

black box logging and siftr. These are the tools that modern developers use. Already touched this topic with rscheff@, tuexen@, rrs@ and jtl@. None of them new what trpt(8) is :) Looks like a good justification to me. -- Gleb Smirnoff

Re: in_pcbbind_setup: wrong condition regarding INP_REUSEPORT ?

his is what SO_REUSEPORT did back in the original BSD stack and this is what it does today in FreeBSD. 20+ years later Linux introduced a different kinds of functionality under the same socket option name, hence the confusion. I can't say much on the INP_REUSEPORT_LB check in the discussed code :( -- Gleb Smirnoff

Re: compressed TIME-WAIT to be decomissioned

. This is not covered by the above (and possibly not M> relevant on the machine you where looking at). Good point. We are not counting this kind of use. -- Gleb Smirnoff

Re: compressed TIME-WAIT to be decomissioned

On Thu, Jan 13, 2022 at 09:11:09PM +0100, Michael Tuexen wrote: M> > On Thu, Jan 13, 2022 at 10:30:10AM -0800, Gleb Smirnoff wrote: M> > T> Sorry, the stats I was talking about are present in CURRENT only: M> > T> M> > T> netstat -sp tcp | grep TIME-WAIT M> >

Re: compressed TIME-WAIT to be decomissioned

On Thu, Jan 13, 2022 at 10:30:10AM -0800, Gleb Smirnoff wrote: T> Sorry, the stats I was talking about are present in CURRENT only: T> T> netstat -sp tcp | grep TIME-WAIT T> 3 times connection in TIME-WAIT responded with ACK T> 0 times connection in TIME-WAIT was ac

Re: compressed TIME-WAIT to be decomissioned

ts I was talking about are present in CURRENT only: netstat -sp tcp | grep TIME-WAIT 3 times connection in TIME-WAIT responded with ACK 0 times connection in TIME-WAIT was actively recycled 0 times connection in TIME-WAIT responded with RST I will merge it to stable/13 today, so that those running 13 can check it out. -- Gleb Smirnoff

Re: compressed TIME-WAIT to be decomissioned

0 times connection in TIME-WAIT responded with RST They show were the TIME-WAITs actually used. -- Gleb Smirnoff

Re: compressed TIME-WAIT to be decomissioned

cerned with amount of TIME-WAITs hanging around can do that on their machines. As you say "2*MSL is pretty old and from a different type of network", so it probably can be reconsidered. But that's a separate thing to discuss. -- Gleb Smirnoff

Re: compressed TIME-WAIT to be decomissioned

On Wed, Jan 12, 2022 at 10:48:59AM -0800, Gleb Smirnoff wrote: T> * Many of HTTP connections were made by older browsers, which were not able T> to use persistent HTTP connections. Those browsers that could, would T> recycle connections more often, then today. Default timeouts in

compressed TIME-WAIT to be decomissioned

e 424+1064 bytes instead of 424+72. Multiply that by expected number of connections in TIME-WAIT on your machine. Comments welcome. -- Gleb Smirnoff

Re: bridge/igb panic: sleepq_add: td 0xfffffe01bbce5300 to sleep on wchan 0xffffffff8157d9a0 with sleeping prohibited

..21%..31%..41%..51%..61%..71%..81%..91% x> x> ___ x> freebsd-curr...@freebsd.org mailing list x> https://lists.freebsd.org/mailman/listinfo/freebsd-current x> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.o

Re: bridge/igb panic: sleepq_add: td 0xfffffe01bbce5300 to sleep on wchan 0xffffffff8157d9a0 with sleeping prohibited

b4aba, rsp = x> 0x7fffe2b8, rbp = 0x7fffe360 --- x> Uptime: 14s x> Dumping 3794 out of 97961 x> MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% x> x> ___ x> freebsd-curr...@freebsd.org mailing list x> h

Re: bridge/igb panic: sleepq_add: td 0xfffffe01bbce5300 to sleep on wchan 0xffffffff8157d9a0 with sleeping prohibited

On Fri, Sep 11, 2020 at 07:45:09PM +0300, xto...@mm.st wrote: x> Gleb Smirnoff wrote: x> >Hi, x> > x> > can you please try out this patch? This is configuration event x> > and we should use sleepable lock to synchronize, not epoch. x> x> It didn'

[Differential] D23788: DRAFT: ng_ksocket: IPv6 address parsing and unparsing

glebius added a comment. In D23788#523247 , @neel_neelc.org wrote: > I still get "ngctl: send msg: Invalid argument" errors with the commands in the Test Plan. Am I doing anything wrong? Well, you've added 3 new places that could return

Re: vtnet IFF_NEEDSEPOCH?

On Thu, Feb 20, 2020 at 12:16:06PM +0100, Kristof Provost wrote: K> On 19 Feb 2020, at 23:48, Gleb Smirnoff wrote: K> > On Tue, Feb 18, 2020 at 10:08:50PM +0100, Kristof Provost wrote: K> > K> So I suspect our call stack is something like virtqueue_intr() -> K&g

Re: vtnet IFF_NEEDSEPOCH?

it’s inside ether_input(), not ether_ifattach(). K> K> ffc00036fff6 : K> { K> ffc00036fff6: 711daddisp,sp,-96 Right, it looks much more like the trace should go via ether_input(), not via ether_ifattach(). K> So I suspect o

Re: vtnet IFF_NEEDSEPOCH?

net_attach() code. K> On the other hand, I run vtnet CURRENT guests in bhyve, and don’t see this K> panic. In that case it lives on top of PCI rather than mmio, but I don’t K> see why/where that’d enter epoch. The transition from ether_ifattach to netisr_dispatch looks strange. Is that somethin

Re: panic: sleeping in an epoch section

Xin, fixed by r353492 On Sun, Oct 13, 2019 at 11:45:46PM -0700, Xin Li wrote: X> X> X> On 2019-10-09 08:07, Gleb Smirnoff wrote: X> > Yes, I we should allow sleep in ifioctl handlers. So this is my fault, I'll X> > handle it today. X> X> It seems that -CURR

Re: panic: sleeping in an epoch section

are you referring to? The locking protocol used by the M> > > multicast code was changed specifically to allow for sleeps in driver M> > > ioctl handlers. M> > M> > I recall a long time ago seeing that input packet processing may end up M> > calling if_ioctl's . Things may have changed since then though. M> M> That may be true in general, but I can't see any instances of that M> for SIOCADDMULTI or SIOCDELMULTI. I think we should always permit ioctl M> handlers to sleep. In particular, the panic reported above is a bug in M> r353292. Yes, I we should allow sleep in ifioctl handlers. So this is my fault, I'll handle it today. -- Gleb Smirnoff ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Relatively deterministic panic with sendfile(2) when running tests in the sxlock code

Enji, can you please check that with this patch all your tests pass? -- Gleb Smirnoff Index: sys/kern/kern_sendfile.c === --- sys/kern/kern_sendfile.c (revision 339098) +++ sys/kern/kern_sendfile.c (working copy) @@ -526,6 +526,8

Re: Relatively deterministic panic with sendfile(2) when running tests in the sxlock code

ted to sendfile but definitely is related to my other changes. Will fix. -- Gleb Smirnoff ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Relatively deterministic panic with sendfile(2) when running tests in the sxlock code

ee/sendfile_tests Клонирование в «sendfile_tests»… fatal: repository 'https://github.com/ngie-eign/freebsd/tree/sendfile_tests/' not found -- Gleb Smirnoff ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-

Re: m_move_pkthdr leaves m_nextpkt 'dangling'

In a datagram socket buffer that could hold a record. (didn't check that, just guessing). So, any objections on commiting this addition to m_move_pkthdr? + to->m_nextpkt = from->m_nextpkt; + from->m_nextpkt = NULL; -- Gleb Smirnoff ___ freebsd-

Re: m_move_pkthdr leaves m_nextpkt 'dangling'

if ((to->m_flags & M_EXT) == 0) A> >>>> to->m_data = to->m_pktdat; A> >>>> to->m_pkthdr = from->m_pkthdr; /* especially tags */ A> >>>> SLIST_INIT(>m_pkthdr.tags); /* purge

[Differential] D9270: Add support for user-supplied Host-Uniq tag and handle PADM messages in Netgraph PPPoE

glebius requested changes to this revision. glebius added a comment. This revision now requires changes to proceed. I got few minor comments. INLINE COMMENTS > ng_pppoe.c:1135 > + /* Generate a packet of that type. */ > + MGETHDR(m, M_NOWAIT, MT_DATA);

Re: listening sockets as non sockets

On Thu, Mar 02, 2017 at 02:00:51PM -0800, Gleb Smirnoff wrote: T> I did similar testing, and my results are the following, for three T> consecutive runs: T> T> solistenhead (r306199) T> req/s63k,63k,63k 46k,47k,44k T> l

Re: listening sockets as non sockets

On Sun, Feb 26, 2017 at 11:37:59PM +0800, Sepherosa Ziehau wrote: S> r314268 -> solisten S> S> 1KB: S> Performance (reqs/s) S> 77916.71 -> 26240.37 S> Latency average S> 121ms -> 294ms ... S> So what I have seen is solisten's performance is 1/3 of r314268, and S> average latency doubles. I did

Re: listening sockets as non sockets

On Sun, Feb 26, 2017 at 11:37:59PM +0800, Sepherosa Ziehau wrote: S> Just got enough time to do some benchmark. The configuration is S> pretty simple, one server box w/ 2x82599, two client boxes w/ 1x82599, S> connected through DAC. nginx-devel is installed through pkg; access S> log is

Re: listening sockets as non sockets

On Tue, Feb 21, 2017 at 09:58:45AM +0100, Julien Charbon wrote: J> > T> 1) The patch worked pretty okay, but the idea of separate file type is J> > T>abandoned. With current filedescriptor code it is almost impossible J> > T>to racelessly switch fileops and f_data. J> > T>For more

Re: listening sockets as non sockets

On Thu, Feb 09, 2017 at 10:30:24PM -0800, Gleb Smirnoff wrote: T> Two important updates. T> T> 1) The patch worked pretty okay, but the idea of separate file type is T>abandoned. With current filedescriptor code it is almost impossible T>to racelessly switch fileop

Re: listening sockets as non sockets

Hi! Two important updates. 1) The patch worked pretty okay, but the idea of separate file type is abandoned. With current filedescriptor code it is almost impossible to racelessly switch fileops and f_data. For more details read the commit message, URL below. 2) I moved the work to

Re: listening sockets as non sockets

Hi Julien, On Fri, Jan 27, 2017 at 03:37:57PM +0100, Julien Charbon wrote: J> I might be able to look at potential race conditions related to J> ACCEPT_LOCK and SO_ACCEPTFILTER usage (even if I am more used to J> INP_INFO lock), but I can certainly provide performance numbers and lock J>

Re: listening sockets as non sockets

On Thu, Jan 26, 2017 at 05:41:17PM -0800, Mark Johnston wrote: M> > It passes regression tests from tools/regression/sockets and tests/sys, M> > including the race tests, and including accept filter ones. M> M> I haven't yet looked much at the diff, so sorry in advance if this M> question is

listening sockets as non sockets

Hi guys, as some of you already heard, I'm trying to separate listening sockets into a new file descriptor type. If we look into current struct socket, we see that some functional fields belong to normal data flow sockets, and other belong to listening socket. They are never used

[Differential] D9345: ifnet: move the new ifnet_event EVENTHANDLER_DECLARE to net/if_var.h

glebius accepted this revision. This revision has a positive review. REVISION DETAIL https://reviews.freebsd.org/D9345 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: decui_microsoft.com, hselasky, sepherosa_gmail.com, cem, np, kmacy, kib,

[Differential] D8904: inet: Fix routing issue by calling if_up()

glebius added a comment. I don't think that the patch is in the right direction. The problem comes from historical behavior that assigning an address is implicit UP. For a modern networking equipment it is a normal administrative situation that sysadmin wants to assign an address or an

[Differential] D8740: remove network mask calculation for Classful network

glebius accepted this revision. glebius added a comment. This revision has a positive review. This looks correct to me. But I haven't reviewed the consequences of writing directly to the "netmask", which is also shared with rarp.c and udp.c Thanks! REVISION DETAIL

Re: FLOWTABLE aka TCP route caching panic

On Mon, Nov 28, 2016 at 02:10:33PM -0800, hiren panchasara wrote: h> > Hi, h> > I have found that last month (19 Oct) the problem appeared on this list, h> > and to my experience it persists, both on VM and bare metal installation h> > (HEAD from yesterday). I looks that enabling FLOWTABLE option

Re: TCP route caching panic

On Thu, Oct 20, 2016 at 12:32:17AM -0500, Mike Karels wrote: M> > On Wed, Oct 19, 2016 at 07:26:44PM -0500, Mike Karels wrote: M> > M> > On Wed, Oct 19, 2016 at 02:29:14PM -0700, Gleb Smirnoff wrote: M> > M> > T> Hi! M> > M> > T> M> > M&

Re: TCP route caching panic

On Wed, Oct 19, 2016 at 07:26:44PM -0500, Mike Karels wrote: M> > On Wed, Oct 19, 2016 at 02:29:14PM -0700, Gleb Smirnoff wrote: M> > T> Hi! M> > T> M> > T> I got this panic in a bhyve VM, which was just compiling stuff M> > T> and had tw

Re: TCP route caching panic

On Wed, Oct 19, 2016 at 02:29:14PM -0700, Gleb Smirnoff wrote: T> Hi! T> T> I got this panic in a bhyve VM, which was just compiling stuff T> and had two ssh sessions open. It has static network configuration, T> one interfaces, one IP address, IPv4 only and it sees only hard

TCP route caching panic

Hi! I got this panic in a bhyve VM, which was just compiling stuff and had two ssh sessions open. It has static network configuration, one interfaces, one IP address, IPv4 only and it sees only hardware address of the host. So it is minimal possible configuration. It runs with INVARIANTS. As

Re: lagg Interfaces - don't do Gratuitous ARP?

On Thu, Sep 22, 2016 at 05:50:09PM +0100, Steven Hartland wrote: S> > S> We could but then what happens when its IPv6 or $other protocol that S> > S> needs to know? That would require lagg to be edited with all the special S> > S> cases instead of allowing the protocol to handle it they way it

Re: lagg Interfaces - don't do Gratuitous ARP?

On Thu, Sep 22, 2016 at 04:52:35PM +0100, Steven Hartland wrote: S> > S> > S> > Does lagg(4) hardware address change when it failovers? S> > S> > S> > S> > S> > S> It moves the address between interfaces which typically moves it between S> > S> > S> switches too. S> > S> > S> > S> > So, the

Re: lagg Interfaces - don't do Gratuitous ARP?

On Thu, Sep 22, 2016 at 04:34:03PM +0100, Steven Hartland wrote: S> On 22/09/2016 16:09, Gleb Smirnoff wrote: S> > On Thu, Sep 22, 2016 at 08:21:08AM +0100, Steven Hartland wrote: S> > S> On 22/09/2016 03:58, Gleb Smirnoff wrote: S> > S> > On Wed, Sep 21, 2016 at 09:1

Re: lagg Interfaces - don't do Gratuitous ARP?

On Thu, Sep 22, 2016 at 08:21:08AM +0100, Steven Hartland wrote: S> On 22/09/2016 03:58, Gleb Smirnoff wrote: S> > On Wed, Sep 21, 2016 at 09:12:11PM -0400, Ryan Stone wrote: S> > R> > IMHO, the original patch was absolutely evil hack touching multiple S> > R> &g

Re: lagg Interfaces - don't do Gratuitous ARP?

On Wed, Sep 21, 2016 at 09:12:11PM -0400, Ryan Stone wrote: R> > IMHO, the original patch was absolutely evil hack touching multiple R> > layers, for the sake of a very special problem. R> > R> > I think, that in order to kick forwarding table on switches, lagg R> > should: R> > R> > - allocate an

Re: lagg Interfaces - don't do Gratuitous ARP?

On Sat, Sep 10, 2016 at 10:51:36PM +1000, Kubilay Kocak wrote: K> > wrote: K> > K> >> Yes known issue I'm afraid. K> >> K> >> I created a patch set to address this but there where objections so K> >> it was removed, see the attached which is based on 10.2-RELEASE. K> >

Re: callout_drain either broken or man page needs updating

On Thu, Jul 14, 2016 at 10:14:46PM -0700, Matthew Macy wrote: M> > On 07/15/16 05:45, Matthew Macy wrote: M> > > glebius last commit needs some further re-work. M> > M> > Glebius commit needs to be backed out, at least the API change that M> > changes the return value when calling

Re: panic with tcp timers

On Mon, Jun 20, 2016 at 12:14:18PM +0200, Hans Petter Selasky wrote: H> On 06/20/16 11:58, Gleb Smirnoff wrote: H> > The fix I am working on now is doing exactly that. callout_reset must H> > return 0 if the callout is currently running. H> > H> > What are the old paths

Re: panic with tcp timers

On Mon, Jun 20, 2016 at 11:55:55AM +0200, Julien Charbon wrote: J> > On Fri, Jun 17, 2016 at 11:27:39AM +0200, Julien Charbon wrote: J> > J> > Comparing stable/10 and head, I see two changes that could J> > J> > affect that: J> > J> > J> > J> > - callout_async_drain J> > J> > - switch to READ

Re: panic with tcp timers

Hi! On Fri, Jun 17, 2016 at 11:27:39AM +0200, Julien Charbon wrote: J> > Comparing stable/10 and head, I see two changes that could J> > affect that: J> > J> > - callout_async_drain J> > - switch to READ lock for inp info in tcp timers J> > J> > That's why you are in To, Julien and Hans :) J>

panic with tcp timers

Hi! At Netflix we are observing a race in TCP timers with head. The problem is a regression, that doesn't happen on stable/10. The panic usually happens after several hours at 55 Gbit/s of traffic. What happens is that tcp_timer_keep finds t_tcpcb being NULL. Some coredumps have tcpcb

Re: long network segment call stack can fail

On Wed, Jan 06, 2016 at 12:50:52PM -0800, Adrian Chadd wrote: A> hah, that's very pretty. The downside of a completely direct-dispatch A> network stack. :) The stack is big, but shouldn't eat 4 pages anyway. Back in the netgraph hacking times, we used to have stack exhaustion with much longer

more net80211 changes :/

Hi! It looks like another sweep over net80211 drivers is required. It isn't going to be as huge as previous one. The problem is that in the "new world order", there will be only if_attach(), instead of if_alloc() / fill & hack / ether_ifattach. What right now happens with net80211 is that

Re: more net80211 changes :/

On Tue, Sep 08, 2015 at 07:31:41PM +0300, Andriy Voskoboinyk wrote: A> > The current patch covers iwn(4) only. Now sending this mail with patched A> > driver. Changing MAC aldo tested - works. A> > A> > I'm starting to convert rest of drivers and meanwhile, waiting for your A> > input. May be you

Re: mbufq-less iwn(4)

On Thu, Sep 03, 2015 at 05:11:27PM +0300, Andriy Voskoboinyk wrote: A> > A> Other thing - ic_transmit() also needs to handle fragments, like I do A> > A> with ath. Ie, handing it a list of packets is actually a list of A> > A> 802.11 fragments, rather than separate MPDUs. A> > A> A> > A> Another

Re: mbufq-less iwn(4)

Adrian, On Tue, Sep 01, 2015 at 12:33:53PM -0700, Adrian Chadd wrote: A> We have to do mbuf queues in drivers for wifi, because of 11n A> aggregation. So on one hand we want to have if_transmit() apply A> backpressure through the stack, but there's also going to be some A> buffering. :P No,

mbufq-less iwn(4)

Hi, Adrian and Andriy! One of the fundamental things that me and Lawrence want to bring to FreeBSD 12 (probably won't be in time with 11), is the NIC TX exhaustion notification to the stack, also named as "network stack backpressure". The problem is that when NICs TX queue is full we start

Re: [head up!] WiFi drivers changes

Good news, thanks! On Thu, Aug 27, 2015 at 06:45:14PM +0200, O. Hartmann wrote: O sory, sorry - I forgot on that specific machine (1 of 5) to mergemaster :-( So, after O mergemaster, the new rc scripts also got installed on the AP server and the interface is O again up and running! O O

Re: [head up!] WiFi drivers changes

Oliver, O Again, O with the most recent changes as of r287211, hostapd doens't start my WiFi AP anymore O (FreeBSD 11.0-CURRENT #7 r287169: Wed Aug 26 20:26:49 CEST 2015 amd64 does!). Let's start investigating from scratch, since the /etc part of the patch have changed significantly. Can you

Re: ix(intel) vs mlxen(mellanox) 10Gb performance

Yonghyeon, On Thu, Aug 20, 2015 at 11:30:24AM +0900, Yonghyeon PYUN wrote: YMaybe it can be controlled by some kind of flag, if all the three TSO Ylimits should include the TCP/IP/ethernet headers too. I'm pretty sure Ywe want both versions. Y Y YHmm, I'm afraid it's

[head up!] WiFi drivers changes

Hi! As part of the opaque ifnet project [1], all 802.11 (WiFi) drivers undergo change of not being an interface anymore. Historically in FreeBSD 802.11 stack, 802.11 devices called if_attach() and created an interface. Later this was generalized and real functioning interface is created by

CFT: ndis(4) testers needed!

Hi! I need to make couple of non-functional but rather large changes to the if_ndis driver and will appreciate if anyone signs up to test my changes. Please contact me if you can provide help. -- Totus tuus, Glebius. ___ freebsd-net@freebsd.org

Re: [Testers needed!] WiFi drivers changes

On Mon, Jun 01, 2015 at 09:01:01PM +0300, Maxim V Filimonov wrote: MAs part of the opaque ifnet project [1], we are doing some code shake M with all IEEE802.11 (read WiFi) drivers. The drivers, that provide a parent M interface for the wlan(4) interface. M MThe core idea is that parent

[Testers needed!] WiFi drivers changes

Hi! As part of the opaque ifnet project [1], we are doing some code shake with all IEEE802.11 (read WiFi) drivers. The drivers, that provide a parent interface for the wlan(4) interface. The core idea is that parent device loses its ifnet(9) structure. The code is already complete for the

Re: ng_netflow

On Tue, May 26, 2015 at 06:36:47PM +0500, Eugene M. Zheganin wrote: E I'm using ng_netflow along with flow-tools to collect traffic statistics. E What is bothering me, is that I constantly see lost flow. What is even E more weird - is that ng_netflow and flow-capture are on the same host, E and

[Differential] [Requested Changes To] D1944: PF and VIMAGE fixes

glebius requested changes to this revision. glebius added a comment. This revision now requires changes to proceed. Thanks a lot, Nikos. I've fixed the problem of sleeping in UMA on kldunload. It was out the scope of the patch. I also committed the first part of the patch - mutexes

Re: should m_copyback possibly throw data away?

On Fri, Apr 24, 2015 at 11:23:08AM -0700, John-Mark Gurney wrote: J John-Mark Gurney wrote this message on Fri, Apr 24, 2015 at 11:11 -0700: J I would also be fine w/ documenting this behavior, though I'm sure J it'd be surprising to many that you'd have to check to make sure your J data was

[Differential] [Commented On] D1944: PF and VIMAGE fixes

glebius added a comment. Recently Nikos has asked questions on kernel debugging. So, I guess, he is working. REVISION DETAIL https://reviews.freebsd.org/D1944 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: nvass-gmx.com, bz, zec, trociny, glebius,

Re: moving struct bpf_if to bpf.c

On Mon, Apr 20, 2015 at 07:52:33PM +, Mark Johnston wrote: M On Mon, Apr 20, 2015 at 10:26:18PM +0300, Gleb Smirnoff wrote: M On Sat, Apr 18, 2015 at 02:08:56PM -0700, Mark Johnston wrote: M M At the moment, bpf.h defines struct bpf_if differently depending on M M whether BPF_INTERNAL

Re: moving struct bpf_if to bpf.c

On Sat, Apr 18, 2015 at 02:08:56PM -0700, Mark Johnston wrote: M At the moment, bpf.h defines struct bpf_if differently depending on M whether BPF_INTERNAL is #defined. This causes problems with CTF, as it M results in a sort of bifurcation within the type graph: CTF sees two M different struct

Re: moving ALTQ out of contrib

On Wed, Apr 15, 2015 at 09:38:23AM +0200, Luigi Rizzo wrote: LWith the new ifnet KPI, that is now being developed in projects/ifnet, L the ALTQ will need some tweaking. It is discontinued by initial author L for a decade now, and it has already experienced direct commits in L our tree.

Re: moving ALTQ out of contrib

On Wed, Apr 15, 2015 at 03:02:03PM +0200, Luigi Rizzo wrote: L L Then if you do sys/net/altq/ do you also plan to split the current L L content of sys/net/ into separate subdirectories ? L L L L We currently have quite a few separate things in sys/net/, such as L L - various bpf files L L -

Re: moving ALTQ out of contrib

On Wed, Apr 15, 2015 at 02:38:21PM +0200, Ermal Luçi wrote: E projects/ifnet, E L the ALTQ will need some tweaking. It is discontinued by initial author E L for a decade now, and it has already experienced direct commits in E L our tree. Thus, I see no good reasons to continue keeping it in

Re: moving ALTQ out of contrib

On Wed, Apr 15, 2015 at 02:53:34PM +0200, Luigi Rizzo wrote: L LWith the new ifnet KPI, that is now being developed in projects/ifnet, L L the ALTQ will need some tweaking. It is discontinued by initial author L L for a decade now, and it has already experienced direct commits in L L

moving ALTQ out of contrib

Hi! With the new ifnet KPI, that is now being developed in projects/ifnet, the ALTQ will need some tweaking. It is discontinued by initial author for a decade now, and it has already experienced direct commits in our tree. Thus, I see no good reasons to continue keeping it in contrib. In

Re: moving ALTQ out of contrib

On Tue, Apr 14, 2015 at 04:53:46PM +0300, Gleb Smirnoff wrote: T Hi! T T With the new ifnet KPI, that is now being developed in projects/ifnet, T the ALTQ will need some tweaking. It is discontinued by initial author T for a decade now, and it has already experienced direct commits in T our

Re: opaque ifnet progress

Anuranjan, On Fri, Apr 03, 2015 at 01:42:49AM +, Anuranjan Shukla wrote: A Hello Gleb, A Thanks for sharing the details. A From looking at the wiki page it's not exactly clear what your plan is A regarding the accessor functions as they stand today (if_get*/if_set* A after drvapi change was

Re: Patch to reduce use of global IP ID value(s) to avoid leaking information

Hans, On Fri, Apr 03, 2015 at 11:16:58PM +0200, Hans Petter Selasky wrote: H What the hell? At Fri, 3 Apr 2015 15:41:21 +0300 (MSK) you ask: H H An expression like that requires a good answer. I've pulled together H some parts and pieces from some existing code to make a test application H

Re: Programmatically Creating VLAN in the Kernel

On Mon, Mar 30, 2015 at 09:49:56AM -0400, Juan Mojica wrote: J I'm trying to programmatically create a VLAN in the kernel via ifioctl, but J I'm hitting a copyin in the ioctl path, and since the address I'm passing J in is a kernel address and not a user space address, the copyin is failing. J J

opaque ifnet progress

Hi! It is already several years as the opaque ifnet has been discussed, and almost a year since it was announced to be worked on. For now I've got a branch in svn, where some proof of concept is done: http://svn.freebsd.org/base/projects/ifnet I've described what's going on in

Re: SIOCSVH, SIOCGVH ioctl(2) and virtio ethernet driver

On Mon, Mar 16, 2015 at 02:49:58AM +0300, Oleg Ginzburg wrote: O b) On FreeBSD-current r276500M CARP IP is established for some seconds, then O vanishes: O O % /sbin/ifconfig vtnet0 vhid 1 advskew 100 pass navuhodonosor 192.168.1.210/24 O state master alias O % ifconfig vtnet0 O vtnet0:

Re: Adding new media types to if_media.h

On Thu, Mar 12, 2015 at 12:01:13PM -0400, John Baldwin wrote: J On Thursday, March 12, 2015 04:07:54 PM Hans Petter Selasky wrote: J On 02/28/15 13:28, John Baldwin wrote: J On Friday, February 27, 2015 10:23:10 PM Gleb Smirnoff wrote: J On Thu, Feb 26, 2015 at 08:25:59PM -0800, Adrian Chadd

Re: Adding new media types to if_media.h

On Thu, Feb 26, 2015 at 10:17:03PM -0600, Mike Karels wrote: M M I'm not sure what would be different about your approach; you mentioned n M M versions rather than x versions of the ioctls, but I don't know what you M M have in mind for encoding. Any compatible version would be limited to

Re: Adding new media types to if_media.h

On Thu, Feb 26, 2015 at 08:25:59PM -0800, Adrian Chadd wrote: A [snip] A A I think Mike's approach is good - it makes it easy to MFC to 10.2 A since there's extended lifecycle stuff to do there - and then we can A plan out how do the betterer fix after it's landed and churned A things. ... and

[Differential] [Updated] D1944: PF and VIMAGE fixes

glebius added a comment. Nikos, acking that I see the patches. Right now I'm waiting for pf to stablize after recent patches to fragment handling. Kristof is working on the known problem. Meanwhile you can finish your patch moving from almost there to there :) If you got any questions about pf

Re: Adding new media types to if_media.h

On Wed, Feb 25, 2015 at 08:58:20PM -0600, Mike Karels wrote: M On Wed, Feb 25, 2015 at 02:42:16PM -0800, Eric Joyner wrote: M E Tbh, I respect Gleb's approach, but developing such a thing would take a M E while; the fix Mike proposed would be a fix now. M E M E I mean, I'd like to see a

[Differential] [Changed Subscribers] D1965: Add extended media types to if_media.h and ifconfig

glebius added a subscriber: glebius. glebius added a comment. We can't and don't plan to preserve the driver KPI for the 11 branch. We actually plan to change it very much, in sake of keeping it stable there on. Please see on what is going on in the projects/ifnet branch. So, I'd suggest to

[Differential] [Commented On] D1965: Add extended media types to if_media.h and ifconfig

glebius added a comment. Is it possible to add Mike Karels to this discussion? REVISION DETAIL https://reviews.freebsd.org/D1965 To: erj, gnn, jfvogel, adrian Cc: glebius, freebsd-net ___ freebsd-net@freebsd.org mailing list

Re: Adding new media types to if_media.h

On Mon, Feb 16, 2015 at 07:50:56PM -0600, Mike Karels wrote: M Well, I developed the prototype as I had planned, using a 64-bit media M word, and found that I got about 100 files in GENERIC that didn't compile; M they attempted to store media words in an int. My kingdom for a typedef. M That

Re: Adding new media types to if_media.h

On Wed, Feb 25, 2015 at 02:17:44PM -0800, Jack Vogel wrote: J So we have products coming soon that need to extend the media, if you have J grandiose plans in the future you can worry about things then, Linux can J handle the extended media TODAY, wouldn't it be nice to do so as well? I didn't

Re: Adding new media types to if_media.h

On Wed, Feb 25, 2015 at 02:42:16PM -0800, Eric Joyner wrote: E Tbh, I respect Gleb's approach, but developing such a thing would take a E while; the fix Mike proposed would be a fix now. E E I mean, I'd like to see a decoupling of media types and speeds from E standard names, and maybe have both

[Differential] [Updated] D1893: Fix special case in ip_fragment() to produce a more sensible chain of packets

glebius added a reviewer: ken. glebius added a comment. This is Ken's code, we probably want him to look at. Looks like a remnant from zero copy era. REVISION DETAIL https://reviews.freebsd.org/D1893 To: hselasky, pluknet, ae, np, melifaro, glebius, hrs, wollman, bryanv, rpaulo, adrian, bz,

[Differential] [Accepted] D1764: Factor out ip6_deletefraghdr()

glebius accepted this revision. This revision is now accepted and ready to land. REVISION DETAIL https://reviews.freebsd.org/D1764 To: kristof, ae, glebius Cc: ae, glebius, freebsd-net ___ freebsd-net@freebsd.org mailing list

[Differential] [Commented On] D1764: Factor out ip6_deletefraghdr()

glebius added a comment. Damn f*ckbrikator doesn't allow me to close the revision, since I don't own it. Kristof, looks like you will need to manually close all your revisions as I commit them. Or we can just leave some trash in this pretty software. REVISION DETAIL

[Differential] [Commented On] D1765: PF: Handle fragmented IPv6 packets

glebius added a comment. Thanks. Now let me complete universe with anonymous structs/unions on. INLINE COMMENTS sys/netpfil/pf/pf_norm.c:88 This line looks like cut-n-paste typo. Don't hurry to fix, I am about to improve the code to use anonymous structure, which, I hope, will be enabled for

[Differential] [Accepted] D1766: Factor out ip6_fragment()

glebius accepted this revision. This revision is now accepted and ready to land. REVISION DETAIL https://reviews.freebsd.org/D1766 To: kristof, glebius Cc: glebius, freebsd-net ___ freebsd-net@freebsd.org mailing list

[Differential] [Accepted] D1765: PF: Handle fragmented IPv6 packets

glebius accepted this revision. This revision is now accepted and ready to land. REVISION DETAIL https://reviews.freebsd.org/D1765 To: kristof, glebius Cc: glebius, freebsd-net ___ freebsd-net@freebsd.org mailing list

[Differential] [Accepted] D1764: Factor out ip6_deletefraghdr()

glebius added a subscriber: glebius. glebius accepted this revision. glebius added a reviewer: glebius. glebius added a comment. This revision is now accepted and ready to land. Thanks. Patch looks good to me, but see comments. We probably need a nod from a IPv6 expert. I'll send link to ae@.

  1   2   3   4   5   6   7   >