Re: fastforward/routing: a 3 million packet-per-second system?

[Juli Mallett]

On Tue, Jul 22, 2014 at 12:23 PM, Carlos Ferreira 
wrote:

> I think the results presented at the paper are regarding one port sending
> or receiving at 14.88Mpps. Using several ports at the same time will surely
> give much lower results. But then again, if one wants 8, 16, 24 or even
> more ports at 10Gb/s, then it should look for FPGA implementations.


This is incorrect and misleading speculation, assuming your hardware is not
set up badly in some way.  With netmap it is quite easy to have additional
threads handling other ports, so long as you have enough real cores to run
those threads on (ideally pinned, and with nothing else running.)  If
you've got the RAM and the CPU, 8 ports of 10GbE with netmap on FreeBSD is
not at all infeasible.  The question is always how much work you need to be
able to do per-packet and whether you're able to do that work in an
efficient way that fits with the model.  So something with a
slightly-specific or at least sneaky architecture is very important here,
so that you can just swap buffers rather than having to do a gratuitous
copy.  And a very careful design even just for parsing the packets, let
alone the process of doing the routing.

Using several ports at the same time on a single CPU absolutely gives lower
results, but someone with 8 10GbE ports can hopefully pretty well handle
providing 16 cores to get the job done and still have a meaningful control
plane.  The idea that netmap or similar solutions would be bottlenecked
otherwise is wrong, unless there's something wrong with your hardware (not
so uncommon as one might like.)  (For cache performance, etc., you really
don't want to use hyperthreads for something as timing-sensitive and
data-hungry as this kind of packet processing; your results may vary.)

Juli.

On 22 July 2014 19:36, John Jasen  wrote:
>
> >
> > On 07/22/2014 01:41 PM, John-Mark Gurney wrote:
> > > John Jasen wrote this message on Tue, Jul 22, 2014 at 11:18 -0400:
> > >> Feedback and/or tips and tricks more than welcome.
> > > You should look at netmap if you really want high PPS routing...
> >
> > Originally, I assumed an interface supporting netmap was required, but
> > the manpage disabuses me of this. Besides, I think the Chelsio cards got
> > netmap recently.
> >
> > I presume either the use of bridge in tools/netmap, or vale-ctl in the
> > same location would start providing me sufficient clue on this?
> > Unfortunately, both seem to be pretty short on verbosity ... More clue
> > is always welcome!
> >
> >
> > ___
> > 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"
> >
>
>
>
> --
>
> Carlos Miguel Ferreira
> Researcher at Telecommunications Institute
> Aveiro - Portugal
> Work E-mail - c...@av.it.pt
> Skype & GTalk -> carlosmf...@gmail.com
> LinkedIn -> http://www.linkedin.com/in/carlosmferreira
> ___
> 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"
>
___
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: Netmap ixgbe stripping Vlan tags

[Juli Mallett]

On Fri, Aug 23, 2013 at 12:02 AM, Andre Oppermann  wrote:

> On 23.08.2013 00:36, Harika Tandra wrote:
>
>> Hi all,
>>
>> I am running Netmap with "intel 10G 82598EB" card in promiscuous mode.
>> While capturing packets via Netmap the driver is stripping off Vlan tags.
>> I tested my setup, I am able to see Vlan tags when the same card is in
>> promiscuous
>> mode without Netmap.
>>
>> This maybe due to the netmap related changes to the device driver code.
>> But I don't know much about drivers. I would appreciate any help or
>> pointer
>> regarding this.
>>
>
> This is standard behavior in FreeBSD drivers where the vlan header is
> removed
> and the vlan tag is placed in an mbuf field.  Together with netmap it
> doesn't
> make sense of course and the driver should disable it when switching to
> netmap
> mode.
>

I think this runs counter to the netmap ethos some (as I understand it.)
 In the same way that netmap doesn't enable promiscuous mode since you may
be doing non-promiscuous processing with netmap, it also should leave
whether VLAN_HWFILTER (or whatever) is enabled up to the program or the
user in question.  It would be nice if it could do the state management for
these things (to ensure the interface goes back to its original state if
the program crashes), but as yet it can't.  There are lots of passive
capture applications where you might not care about having the VLAN tags
intact and so would prefer to have them stripped.  If there's a bug here,
it's that packet metadata is lost going into netmap entirely, not that the
VLAN tags aren't in the frame.


> The general usefulness of hardware vlan tag stripping/insertion is
> debatable as
> it doesn't gain much, if anything, and was intended for an entirely
> different
> purpose, namely to help the windows kernel over its total lack of vlan
> awareness.
>

It also helps (slightly) reduce overhead in packet processing where you
just want to move data from card to host as fast as possible.


> It can be argued that in FreeBSD hardware vlan tag insert/removal is an
> unnecessary
> misfeature and only complicates things.  Especially in the context of
> multi-vlan
> stacking.  Doing it in software would be in fact just as fast remove a bit
> of code
> from the drivers.


Are you sure?  While that may hold up for ixgbe (though I'd say it doesn't,
at least without packets going straight into cache so there's no penalty
for accessing parts of the packet you don't care about, again looking at
the netmap case really) it doesn't hold up for low-powered network
processors with very fast offload engines.  (NB: I'd rather see it gone; I
think it's an annoying complication when writing network drivers [which
have way too many fiddly bits; I was bound to dislike some aspect of 'tools
not policy' eventually, I guess], or if it stays I'd rather see it be a
mandatory option on hardware where there's no penalty for using it.  Some
hardware's performance falls off spectacularly with this kind of offloading
enabled, losing whatever gains stripping unnecessary data provided.)

Thanks,
Juli.
___
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: Capture packets before kernel process

[Juli Mallett]

On Tue, Apr 30, 2013 at 8:24 AM,   wrote:
> I need some help, currently I'm working in a project where I want to capture
> and process some network packets before the kernel. I have searched but I
> have found nothing.
>
> Is there some way to capture the packets before the kernel ?

You probably should look at netmap, although you need supported hardware:
- http://info.iet.unipi.it/~luigi/netmap/

It can even be configured so that you can pass some packets on to the
regular kernel network stack, although it's not clear if that's
something you want/need.

Thanks,
Juli.
___
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: TF_NEEDSYN flag never set.

[Juli Mallett]

On Sun, Apr 28, 2013 at 3:31 PM, Barry Spinney  wrote:
> (p.s. I doubt it matters which version of code, but to be precise this is 
> from the
> /pub/FreeBSD/development/tarballs named "src_stable_6.tar.gz" dated 
> "4/21/2013 01:15 AM",
> gotten from ftp1.us.freebsd.org)

Barry, of course the version of code matters :)

You might try using FXR for these sorts of lookups in the future:
http://fxr.watson.org/fxr/ident?i=TF_NEEDSYN

Or just check out -CURRENT using Subversion.  Or are you actually
working on 6.x and so need an answer for 6.x?

Thanks,
Juli.
___
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: splitting m_flags to pkthdr.flags + m_flags

[Juli Mallett]

On Fri, Nov 2, 2012 at 5:54 AM, Andre Oppermann wrote:

> On 02.11.2012 13:38, Gleb Smirnoff wrote:
>
>> #define M_SKIP_FIREWALL 0x4000 /* skip firewall processing */
>>
>
> This one should become an M_PROTO overlay.  It is only relevant within
> a protocol layer.


No, like M_PROMISC it needs to follow packets around throughout the stack,
and not conflict with anything else.  My memory of the details is a bit
hazy, but ipfw2 unfortunately does need the flag to not be something that
could be accidentally set or cleared by another protocol layer, and the
flag needs to persist.  Or did 8 years ago.

http://svnweb.freebsd.org/base?view=revision&revision=132274

But there was some disagreement at the time about whether ipfw2 was doing
the right thing, and this behavior should be legitimized by making it
actually work right:

http://lists.freebsd.org/pipermail/cvs-src/2004-July/027830.html

If the flag is made back into an M_PROTO (or, even better, removed) then it
would be best to verify that it does not need to persist, it is okay if the
flag is set by a different protocol layer, etc., today.

Thanks,
Juli.
___
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: What does adapter->stats.mpc[] report for ixgbe?

[Juli Mallett]

On Mon, May 7, 2012 at 9:42 PM, Vijay Singh  wrote:
>> normal net traffic. But for now in FreeBSD its just one which is divided
>> into 3 parts: TX, RX, and FDIR (flow director).
>
> Jack, does the sw driver control in any way the partitioning of the
> FIFO? I guess enabling 2 hw queues splits the FIFO in half. But
> otherwise does the driver control this in any way?

I don't believe that multiple queues splits the FIFO (Jack can correct
me if I'm wrong.)  This is a small (very small) chunk of low-latency
memory on the NIC itself that is used to store the packets as they
come in off the wire before they are moved to a receive descriptor.
The driver does have a way of partitioning the space between transmit
and receive, look for "PBA" in the drivers.  In some cases if you're
doing mostly-transmit or mostly-receive it can be very helpful to
tweak these values, but in the case where you're running out of
receive FIFO space constantly, it's (in my limited experience) more
likely to be a problem with bandwidth or latency between the NIC and
main memory, causing backpressure within the NIC as it tries to move
packets to receive buffers (which are the ones allocated in main, i.e.
host, memory.)
___
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: What does adapter->stats.mpc[] report for ixgbe?

[Juli Mallett]

While we're on the subject, I've had some confusion for some time now:

On Mon, May 7, 2012 at 5:25 PM, Jack Vogel  wrote:
> Packets are missed when the receive FIFO has insufficient space to store the
> incoming packet.

This means the on-card FIFO, i.e. the fixed-size FIFO that is divided
into receive and transmit space by the driver, right?  And the
separate "receive no buffers" counter records instances where the
packet made it to the card but there was no buffer associated with a
receive descriptor to write it to?  That has been my interpretation of
the documentation and the numbers I've seen in practice, but I've seen
conflicting interpretations and would much rather hear it from the
horse's mouth :)

Thanks,
Juli.
___
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: igb(4) at peak in big purple

[Juli Mallett]

Hey Barney,

On Tue, May 1, 2012 at 11:13, Barney Cordoba  wrote:
> --- On Fri, 4/27/12, Juli Mallett  wrote:
> > [Tricking Intel's cards into giving something like round-robin packet
> >  delivery to multiple queues.  ]
>
> That seems like a pretty naive approach. First, you want all of the packets 
> in the same flows/connections to use the same channels, otherwise you'll
> be sending a lot of stuff out of sequence.

I wouldn't call it naive, I'd call it "oblivious".  I feel like I went
to some lengths to indicate that it was not the right solution to many
problems, but that it was a worthwhile approach in the case where one
doesn't care about anything but evenly distributing packets by number
(although size is also possible, by using a size-based watermark
rather than a count-based one) to as many queues as possible.  Not
every application requires in-sequence packets (indeed,
out-of-sequence traffic can be a problem even with flow affinity
approaches.)

My note was simply about the case where you need to evenly saturate
queues to divide up the work as much as possible, on hardware that
doesn't make it possible to get the behavior you want (round-robin by
packet) for that case.  Intel's hardware has the redirection table,
which makes it possible (with a very application-aware approach that
is anything but naive) to get functionality from the hardware that
isn't otherwise available at a low-level.  Few of the things you
assert are better are available from Intel's cards — if you want to
talk about optimal hardware multi-queue strategies, or queue-splitting
in software, that's a good conversation to have and this may even be
the right list, but I'd encourage you to just build your own silicon
or use something with programmable firmware.  For those of us saddled
with Intel NICs, it's useful to share information on how to get
behavior that may be desirable (and I promise you it is for a large
class of applications) but not marketed :)

> You want to balance your flows,
> yes, but not balance based on packets, unless all of your traffic is icmp.
> You also want to balance bits, not packets; sending 50 60 byte packets
> to queue 1 and 50 1500 byte packets to queue 2 isn't balancing. They'll
> be wildly out of order as well.

This is where the obliviousness is useful.  Traffic has its own
statistical distributions in terms of inter-packet gaps, packet sizes,
etc.  Assume your application just keeps very accurate counters of how
many packets have been seen with each Ethernet protocol type.  This is
a reasonable approximation of some real applications that are
interesting and that people use FreeBSD for.  You don't care how big
the packets are, assuming your memory bandwidth is infinite (or at
least greater than what you need) — you just want to be sure to see
each one of them, and that means making the most of the resources you
have to ensure that even under peak loads you cannot possibly drop any
traffic.

Again, not every application is like that, and there's a reason I
didn't post a patch and encourage the premature-tuning crowd to give
this sort of thing a try.  When you don't care about distributing
packets evenly by size, you want an algorithm that doesn't factor them
in.  Also, I've had the same concern that you now have previously, and
in my experience it's mostly magical thinking.  With many kinds of
application and many kinds of real-world traffic it really doesn't
matter, even if in theory it's a possibility.  There's no universal
solution to packet capture that's going to be optimal for every
application.

> Also, using as many cores as possible isn't necessarily what you want to
> do, depending on your architecture.

I think Sean and I, at least, know that, and it's a point that I have
gone on about at great length when people endorse the go-faster
stripes of using as many cores as possible, rather than as many cores
as necessary.

> If you have 8 cores on 2 cpus, then you
>  probable want to do all of your networking on four cores on one cpu.
> There's a big price to pay to shuffle memory between caches of separate
> cpus, splitting transactions that use the same memory space is
> counterproductive.

Not necessarily — you may not need to split transactions with all
kinds of applications.

> More  queues mean more locks, and in the end, lock contention is your biggest 
> enemy, not cpu cycles.

Again, this depends on your application, and that's a very naive
assertion :)  Lock contention may be your biggest enemy, but it's only
occasionally mine :)

> The idea that splitting packets that use the same memory and code space
> among cpus isn't a very good one; a better approach, assuming you can

You're making an assumption that wasn't part of the conve

Re: igb(4) at peak in big purple

[Juli Mallett]

On Fri, Apr 27, 2012 at 12:29, Sean Bruno  wrote:
> On Thu, 2012-04-26 at 11:13 -0700, Juli Mallett wrote:
>> Queue splitting in Intel cards is done using a hash of protocol
>> headers, so this is expected behavior.  This also helps with TCP and
>> UDP performance, in terms of keeping packets for the same protocol
>> control block on the same core, but for other applications it's not
>> ideal.  If your application does not require that kind of locality,
>> there are things that can be done in the driver to make it easier to
>> balance packets between all queues about-evenly.
>
> Oh? :-)
>
> What should I be looking at to balance more evenly?

Dirty hacks are involved :)  I've sent some code to Luigi that I think
would make sense in netmap (since for many tasks one's going to do
with netmap, you want to use as many cores as possible, and maybe
don't care about locality so much) but it could be useful in
conjunction with the network stack, too, for tasks that don't need a
lot of locality.

Basically this is the deal: the Intel NICs hash of various header
fields.  Then, some bits from that hash are used to index a table.
That table indicates what queue the received packet should go to.
Ideally you'd want to use some sort of counter to index that table and
get round-robin queue usage if you wanted to evenly saturate all
cores.  Unfortunately there doesn't seem to be a way to do that.

What you can do, though, is regularly update the table that is indexed
by hash.  Very frequently, in fact, it's a pretty fast operation.  So
what I've done, for example, is to go through an rotate all of the
entries every N packets, where N is something like the number of
receive descriptors per queue divided by the number of queues.  So
bucket 0 goes to queue 0 and bucket 1 goes to queue 1 at first.  Then
a few hundred packets are received, and the table is reprogrammed, so
now bucket 0 goes to queue 1 and bucket 1 goes to queue 0.

I can provide code to do this, but I don't want to post it publicly
(unless it is actually going to become an option for netmap) for fear
that people will use it in scenarios where it's harmful and then
complain.  It's potentially one more painful variation for the Intel
drivers that Intel can't support, and that just makes everyone
miserable.

Thanks,
Juli.
___
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: igb(4) at peak in big purple

[Juli Mallett]

On Thu, Apr 26, 2012 at 11:07, Sean Bruno  wrote:
> I note form top that igb0 queue 0 is always "more busy" than any other
> queue, there appears to be a second kernel igb0 "queue" process/thread
> that appears to be moderately busy and 3 kernel igb0 "queue"
> processes/threads that appear to be doing nothing in particular.

Queue splitting in Intel cards is done using a hash of protocol
headers, so this is expected behavior.  This also helps with TCP and
UDP performance, in terms of keeping packets for the same protocol
control block on the same core, but for other applications it's not
ideal.  If your application does not require that kind of locality,
there are things that can be done in the driver to make it easier to
balance packets between all queues about-evenly.

I've also seen it be the case that some cores will use more CPU time
for reasons of unusually-slow memory access from that core, i.e. with
non-uniform memory, or with some CPU threads, rather than because more
packets are going to a queue.  It would certainly be very nice at some
point for netstat -I to grow awareness of multiple queues (which is a
bit non-trivial because of how those statistics are gathered from
struct ifnet) so that one could more easily watch in real time the
packet rate to each queue.  Probably someone with more patience than
me could do this using the sysctl nodes the drivers export.

Juli.
___
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: igb(4) Pondering a bind to cpu patch

[Juli Mallett]

On Tue, Apr 24, 2012 at 17:11, Sean Bruno  wrote:
> http://people.freebsd.org/~sbruno/if_igb.c.txt
>
> 8 core machine
> 2 igb(4) interfaces
> set num_queues=4
>
> igb0:0 --> cpu0
> [...]
> igb1:0 --> cpu0
> [...]
>
> I suspect, that we need a static global to keep track of what cpu last
> was last bound to a queue.  My patch does do this, but I don't know if
> its the right thing.
>
> Since I'm doing multiple interfaces, I need to make sure I don't
> schedule a queue to a non existent cpu, so take a modulo of the counter
> and the number of cpus in the box.

This seems like a plausible approach, and certainly much more DWIM
than what I've done in the past, which is to use cpuset with -x to
bind each IRQ to a core by hand.  If there were a way for interfaces
to export queue information including any relevant IRQs, it would be
easy to make a frontend that would use cpuset in a usable way, but
right now that's the solution I've found most tenable and uninvasive.
The question here is what behavior to assume the user wants when they
restrict the number of queues, which is why putting the policy bits
into userland would be preferable to this sort of scheme, I suppose.
___
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: Why host transmit rate on 1Gb ethernet is only ~750Mbps ?

[Juli Mallett]

On Sat, Apr 14, 2012 at 18:14, Jason Leschnik  wrote:
> What about the results on the end node, during the testing?.

This is not a very quick way to isolate the problem.  Some NICs and
some configurations just can't do line rate at any packet size, or at
any plausible packet size, and if that's the case then looking at load
isn't very instructive unless interrupt load is the problem.  iperf
with UDP is already pretty basic and not very resource-hungry.  I've
pushed a gigabit with iperf and UDP on pretty trivial hardware, and
had problems with high-end hardware and a low-end NIC.

2.5GHz CPU is not enough information.  How is the re device attached?
What kind of 2.5GHz CPU?

If you have netgraph in your kernel and ng_source, you can use it
pretty easily.  Dump a real packet or dd some random data into a file
called "packet-source".  Make it the size of the frame size you want
to test.  Put in a real packet header and then use truncate(1) to
adjust its size for a variety of tests.

These examples below assume your NIC is called e0 — replace that with
whatever your NIC is really called.

In one window, run netstat -w1 -I e0.

In another, run this shell script:

%%%
#! /bin/sh

sudo ngctl mkpeer e0: source orphans output
sudo nghook e0:orphans input < packet-source
sudo ngctl msg e0:orphans start 10
%%%

When you want to stop it, just do "sudo ngctl destroy e0:orphans" (I
may have that wrong.)

Now, watch your packet output rate and bandwidth in netstat.  Is it
managing 1gbps, or hovering at 750mbps?  If the latter, you're not
going to get better performance without driver tweaks, and maybe not
even then.  If you want to put netmap (not netgraph) into your kernel
and try its pkt-gen program (in tools/tools/netmap/pkt-gen.c IIRC) you
may be able to see if that's better, in which case interrupt overhead
may be your issue, in which case you're probably still out-of-luck
unless you want to hack the driver or make your application use
netmap.

Now, on your other host, the one receiving this traffic, put the
interface in promiscuous mode.  Run netstat -w1 -I {whatever} to watch
its receive rate.  Is it receiving all of the packets that are getting
sent?

If the source is managing to send 1gbps and the target is receiving
less, there's your problem.  If they can both do it, then your
bottleneck is somewhere between the Ethernet stack and iperf, but it's
likely not CPU time unless you're trying to send very small frames,
and even then 2.5GHz can probably swing it.  I have a 3GHz (IIRC)
NetBurst Xeon that can to 980mbps with infinitesimal frames, and it's
rubbish.  Builds world in about a light year* and has the disk
performance of a muddy lake full of boating enthusiasts.  It just
doesn't take much CPU time to blithely spew traffic forth, even with
iperf.

Good luck!

*: Not an actual unit of measurement of wall, system, user or real time.
___
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: nmbclusters: how do we want to fix this for 8.3 ?

[Juli Mallett]

On Sat, Mar 24, 2012 at 13:33, Jack Vogel  wrote:
> On Sat, Mar 24, 2012 at 1:08 PM, John-Mark Gurney  wrote:
>> If we had some sort of tuning algorithm that would keep track of the
>> current receive queue usage depth, and always keep enough mbufs on the
>> queue to handle the largest expected burst of packets (either historical,
>> or by looking at largest tcp window size, etc), this would both improve
>> memory usage, and in general reduce the number of require mbufs on the
>> system...  If you have fast processors, you might be able to get away with
>> less mbufs since you can drain the receive queue faster, but on slower
>> systems, you would use more mbufs.
>
> These are the days when machines might have 64 GIGABYTES of main storage,
> so having sufficient memory to run high performance networking seems little
> to
> ask.

I think the suggestion is that this should be configurable.  FreeBSD
is also being used on systems, in production, doing networking-related
tasks, with <128MB of RAM.  And it works fine, more or less.

>> This tuning would also fix the problem of interfaces not coming up since
>> at boot, each interface might only allocate 128 or so mbufs, and then
>> dynamicly grow as necessary...
>
> You want modern fast networked servers but only giving them 128 mbufs,
> ya right , allocating memory takes time, so when you do this people will
> whine about latency :)

Allocating memory doesn't have to take much time.  A multi-queue
driver could steal mbufs from an underutilized queue.  It could grow
the number of descriptors based on load.  Some of those things are
hard to implement in the first place and harder to cover the corner
cases of, but not all.

> When you start pumping 10G...40G...100G ...the scale of the system
> is different, thinking in terms of the old 10Mb or 100Mb days just doesn't
> work.

This is a red herring.  Yes, some systems need to do 40/100G.  They
require special tuning.  The default shouldn't assume that everyone's
getting maximum pps.  This seems an especially-silly argument when
much of the silicon available can't even keep up with maximum packet
rates with minimally-sized frames, at 10G or even at 1G.

But again, 1G NICs are the default now.  Does every FreeBSD system
with a 1G NIC have loads of memory?  No.  I have an Atheros system
with 2 1G NICs and 256MB of RAM.  It can't do anything at 1gbps.  Not
even drop packets.  Why should its memory usage model be tuned for
something it can't do?

I'm not saying it should be impossible to allocate a bajillion
gigaquads of memory to receive rings, I certainly do it myself all the
time.  But choosing defaults is a tricky thing, and systems that are
"pumping 10G" need other tweaks anyway, whether that's enabling
forwarding or something else.  Because they have to be configured for
the task that they are to do.  If part of that is increasing the
number of receive descriptors (as the Intel drivers already allow us
to do — thanks, Jack) and the number of queues, is that such a bad
thing?  I really don't think it makes sense for my 8-core system or my
16-core system to come up with 8- or 16-queues *per interface*.  That
just doesn't make sense.  8/N or 16/N queues where N is the number of
interfaces makes more sense under heavy load.  1 queue per port is
*ideal* if a single core can handle the load of that interface.

> Sorry but the direction is to scale everything, not pare back on the network
> IMHO.

There is not just one direction.  There is not just one point of
scaling.  Relatively-new defaults do not necessarily have to be
increased in the future.  I mean, should a 1G NIC use 64 queues on a
64-core system that can do 100gbps @ 64 bytes on one core?  It's
actively-harmful to performance.  The answer to "what's the most
sensible default?" is not "what does a system that just forwards
packets need?"  A system that just forwards packets already needs IPs
configured and a sysctl set.  If we make it easier to change the
tuning of the system for that scenario, then nobody's going to care
what our defaults are, or think us "slow" for them.
___
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"

MSI-X + em(4) = Refresh mbufs: hdr dmamap load failure - 22

[Juli Mallett]

All,

On both stable/9 and trunk I see that with one of either the 82571EB
or 82574L I am flooded with messages in the form of:

Refresh mbufs: hdr dmamap load failure - 22

If I disable msix, then the messages go away.  I am not sure why msix
vs. non-msix would matter in this case unless in the msix case there's
some kind of case of spurious interrupts causing em_rxeof to be called
without any packets available.  If that happens then perhaps
e1000_rx_unrefreshed() is called when no buffers have been processed
and then em_refresh_mbufs wrongly refreshes the whole ring?

This seems like it would be a problem because the
bus_dmamap_load_mbuf_sg code is called unconditionally, even when a
new mbuf isn't being allocated.  In that case, the mapping already
exists.  Wouldn't it be necessary to unload and then reload the mbuf?
So either it's a bug that em_refresh_mbufs is being called at all, or
it's naively reusing mbufs in a way that actually guarantees an error,
right?  Also, in the case where it frees, only m_free is called — is
there never a case where that should be an m_freem?  I can imagine
some, but they are likely impossible with the receive path of the
driver.  (I don't know for sure because the receive path and the mbuf
refresh code keep changing and I've been unable to keep up.)

I don't know which part it is, of course, because I don't know what
port it's coming from.  Like three other printfs in the driver where
which device is being used matters tremendously, it uses a bare printf
and not a device_printf.  I could modify the driver, but for now
disabling msix is easier than continuing to load new kernels to try to
debug the problem.

Is anyone else seeing this?  Has anyone further investigated the
problem?  Is there a patch floating around and I just haven't found
the right search terms?

Thanks in advance,
Juli.

PS: Yes, I know this is kind of a crappy bug report, sorry.  I've had
a limited amount of time to investigate so far, and don't want to
delay reporting it until I am able to get more time with the
problematic hardware.
___
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: Network Interface configuration

[Juli Mallett]

On Wed, Mar 7, 2012 at 01:24, hiren panchasara
 wrote:
> On Wed, Mar 7, 2012 at 12:49 AM, Juli Mallett  wrote:
>>  In general, interfaces do
>> not come from the configuration files like rc.conf, however the way
>> that those interfaces are set up on boot is configured by files like
>> rc.conf.
>
>
> Thanks Juli.
> So, does it mean that looking at getifaddrs() is the best way (as ifconfig
> is doing) to get the correct state of network interfaces at any point in
> time?

Yes.

> And for the interface of your interest, you can check if rc.conf is
> specifying any persistent configuration or not.

Pretty much.  There are other ways one could configure the interfaces
persistently (for example, a series of ifconfig commands in rc.local)
but in general rc.conf is the way to go, unless you decide to build
your own configuration system.
___
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: Network Interface configuration

[Juli Mallett]

On Wed, Mar 7, 2012 at 00:21, hiren panchasara
 wrote:
> On Wed, Mar 7, 2012 at 12:08 AM, Damien Fleuriot  wrote:
>> In /etc/rc.conf
>>
>> See the man page for rc.conf for a more detailed use.
>> See the small example bellow:
>>
>> ifconfig_re0="inet 192.168.0.30/24 up"
>> defaultrouter="192.168.0.254"
>>
>> These are the very basics ;)
>>
>
> Thanks Damien.
>
> I looked at the man page. I did "ifconfig" on my box and found an interface
> named fwe0. I do not see any entry for that in any /etc/rc.conf or
> /etc/defaults/rc.conf
>
> Where is that coming from?
>
> Am I missing anything?

Interfaces are created based on what is present in the kernel and what
hardware is present on your system.  The configuration of those
interfaces (e.g. associated IP addresses, media options, etc.) is done
at runtime by scripts in /etc.  Those scripts use rc.conf to determine
how to configure the interfaces.  So if you do:

ifconfig_bge0="inet 192.168.0.1/24"

Then your bge0 interface will be configured with those settings on
boot (or when you do /etc/rc.d/netif restart).  If there is no bge0
interface on your system, however, because the hardware is not present
or the driver is not in your kernel (or loaded as a module), then
nothing will happen.  That interface will not be created.

You can create some kinds of interfaces dynamically, and you can
rename interfaces, but those things are probably a distraction from
what you want and excessively confusing.  In general, interfaces do
not come from the configuration files like rc.conf, however the way
that those interfaces are set up on boot is configured by files like
rc.conf.
___
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: nmbclusters: how do we want to fix this for 8.3 ?

[Juli Mallett]

On Thu, Feb 23, 2012 at 07:19, Ivan Voras  wrote:
> On 23/02/2012 09:19, Fabien Thomas wrote:
>> I think this is more reasonable to setup interface with one queue.
>
> Unfortunately, the moment you do that, two things will happen:
> 1) users will start complaining again how FreeBSD is slow
> 2) the setting will be come a "sacred cow" and nobody will change this
> default for the next 10 years.

Is this any better than making queue-per-core a sacred cow?  Even very
small systems with comparatively-low memory these days have an
increasing number of cores.  They also usually have more RAM to go
with those cores, but not always.  Queue-per-core isn't even optimal
for some kinds of workloads, and is harmful to overall performance at
higher levels.  It also assumes that every core should be utilized for
the exciting task of receiving packets.  This makes sense on some
systems, but not all.

Plus more queues doesn't necessarily equal better performance even on
systems where you have the memory and cores to spare.  On systems with
non-uniform memory architectures, routinely processing queues on
different physical packages can make networking performance worse.

More queues is not a magic wand, it can be roughly the equivalent of
go-faster stripes.  Queue-per-core has a sort of logic to it, but is
not necessarily sensible, like the funroll-all-loops school of system
optimization.

Which sounds slightly off-topic, except that dedicating loads of mbufs
to receive queues that will sit empty on the vast majority of systems
and receive a few packets per second in the service of some kind of
magical thinking or excitement about multiqueue reception may be a
little ill-advised.  On my desktop with hardware supporting multiple
queues, do I really want to use the maximum number of them just to
handle a few thousand packets per second?  One core can do that just
fine.

FreeBSD's great to drop-in on forwarding systems that will have
moderate load, but it seems the best justification for this default is
so users need fewer reboots to get more queues to spread what is
assumed to be an evenly-distributed load over other cores.  In
practice, isn't the real problem that we have no facility for changing
the number of queues at runtime?

If the number of queues weren't fixed at boot, users could actually
find the number that suits them best with a plausible amount of work,
and the point about FreeBSD being "slow" goes away since it's perhaps
one more sysctl to set (or one per-interface) or one (or one-per)
ifconfig line to run, along with enabling forwarding, etc.

The big commitment that multi-queue drivers ask for when they use the
maximum number of queues on boot and then demand to fill those queues
up with mbufs is unreasonable, even if it can be met on a growing
number of systems without much in the way of pain.  It's unreasonable,
but perhaps it feels good to see all those interrupts bouncing around,
all those threads running from time to time in top.  Maybe it makes
FreeBSD seem more serious, or perhaps it's something that gets people
excited.  It gives the appearance of doing quite a bit behind the
scenes, and perhaps that's beneficial in and of itself, and will keep
users from imagining that FreeBSD is slow, to your point.  We should
be clear, though, whether we are motivated by technical or
psychological constraints and benefits.

Thanks,
Juli.
___
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: Abstracting struct ifnet

[Juli Mallett]

On Mon, Feb 20, 2012 at 16:37, Adrian Chadd  wrote:
> On 20 February 2012 16:15, Luigi Rizzo  wrote:
>
>>> The concept seems fine to me and I like that it might simplify future
>>> API changes.  Have you verified that if_get_*() accessors don't add
>>> significant overhead?
>>
>> the vast majority of these fields are only accessed in the control path,
>> not on each packet, so there isn't really a performance issue. Besides
>> they can be trivially implemted as macros or inline functions.
>
> I doubt Juniper need _binary_ level compatibility. So we could get
> away with inline methods.
>
> This sort of thing just makes source level compatibility a lot easier.

It's not just about Juniper, though, it's about us, and how much this
buys us.  Using inlines buys us some source compatibility and the
ability to add some invariants, but is no different to macros in terms
of KBI within a version of FreeBSD, or between versions.  We can't
make ifnet opaque with inlines.  Adding a member to ifnet which is
opaque[*] and which has the fields most likely to change in size,
order, existence, etc., and leaving a few that are needed in the fast
path and will be used by macros/inlines is probably where we should
end up.

*: Obviously ifnet should be a value member of the opaque type, and
the ifnet should include a pointer to the opaque type, or something
like that, since you can't make an opaque struct a value member, which
is probably obvious, but I wanted to be clearish.
___
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: Abstracting struct ifnet

[Juli Mallett]

On Mon, Feb 20, 2012 at 18:34, Adrian Chadd  wrote:
> Is the target though _binary_ compatibility? Just having a blessed
> method of doing accessor method things will buy more source
> flexibility. The KBI can stay the same in the default case and IMHO
> this kind of thing gives developers more power to do smart invariant
> and debugging things.

KBI compatibility requires very little discipline and makes loadable
modules for network drivers much less hellish.  Inlines, macros and
full visibility of ifnet in -current may be useful, but unless there's
a performance reason for doing so, retaining KBI compatibility *and*
the ability to merge ifnet changes to -stable sounds pretty nice to
me.

> Being able to say "inform me every time an interface flag changes"
> would actually be kind of nice when debugging some of the issues i've
> been facing with ath. I've been half tempted to do this -inside- the
> ath driver, partially to restore the OS portability it once tried to
> achieve.

I think that it is rare that this is useful in debugging, and
something of a red herring.  Even invariants are almost a red herring:
really, we shouldn't be using these individual methods to tweak
structure fields, either, we should have a way of describing a network
driver more semantically, such that the invariants are richer and also
not as complicated, and also more comprehensive.

Source compatibility is the biggest win, but a little self-discipline
to win what measure of binary compatibility we can seems perfectly
sensible.

(And at some point, we could even replace ifnet with something that's
less of a strange grab bag assortment that's awkward to explain to new
driver writers, and keep both source and binary compatibility for a
reasonable period in doing so.  Unlikely to happen in the near term,
but wouldn't it be nice?
___
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: Ethernet Switch Framework

[Juli Mallett]

On Sat, Jan 28, 2012 at 14:12, Aleksandr Rybalko  wrote:
> As I see from your patch, mdio/miiproxy require special bits in MAC
> driver. When I design switch framework, I keeping in mind that
> MAC drivers should be standard as possible

I don't understand why this is desirable in practice.  It's a nice
theory, but it falls down when one thinks in depth about how Ethernet
interfaces are used and administered vs. how switches are used and
administered.  What should media report?  What should media changes
do?  What is link status?  Do you show the CPU-to-switch port, or all
switch ports?

It makes me wonder if the understanding of the relationship in FreeBSD
isn't backwards.  Yes, the MAC sits on a bus and is memory-mapped, but
you can conceptualize of it as a child of the PHY, rather than the
parent of it, especially in systems with switch chipsets.  Especially
in systems where there is a switch chipset attached to multiple MACs.

In that model, it makes sense to semi-generically attach a
CPU-to-switch port's pseudo-PHY (or actual PHY, depending on hardware)
to a MAC generically, but that doesn't meant that the switch itself is
attached generically to the MAC.

There are a lot of switches out there that don't look or act much like
MII-driven PHYs, but which are connected over MDIO, as I've tried to
stress before.  I hope there will be as much separation between the
MII work that is being done and the switch work that is being done as
possible.  I think anything else will prove rapidly-obsolete and
perhaps even obstructive as soon as anyone seeks to add support for
more switch chipsets to FreeBSD.

I suppose the most likely reality, though, is that people simply won't
add switch support to FreeBSD, and will administer them out-of-band
from userland, using gross kernel shims.  That is probably true
whether any of the currently-outstanding work is committed or not,
unfortunately :(  I just hope we'll end up with something flexible
enough, broad enough in applicability, narrow enough in requirements,
etc., that we'll have feature-rich support for a few chipsets in tree
that work in sufficiently-different manners that they can be models
for other drivers in the future.

Thanks,
Juli.
___
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: vlan without ip address

[Juli Mallett]

On Sat, Dec 31, 2011 at 03:26, saeedeh motlagh
 wrote:
> thank you guys for your answers but my problem is not solved yet:((
>
> the thing is, i wanna have something like this:
> a freebsd box which acts like switch (for example cisco 2960). i want to
> define vlanX on one interface (without any ip address) and it tags any
> passing packets through that interface as vlanX (any passing packet will
> have vlanX ID).

Did you see my previous message about VLAN interfaces in FreeBSD not
being like the VLANs one can define in a switch?  You do not need the
interface to add any tag to incoming packets, if that is what you are
saying.  Have you tried just bridging the interfaces without VLANs to
see if that does what you want?

You may also be adding the VLAN in the wrong place.  If you create an
interface em0.4, which is tagged VLAN 4 on em0, then any incoming
packet on em0 which has a VLAN tag of 4 will appear on em0.4.  If you
send any packets on em0.4, then they will be sent out em0 with a VLAN
tag of for VLAN 4 added.  Is that what you want?

It may be helpful for you to draw us a diagram.  Use specific
examples.  Show an incoming packet.  Does it have a VLAN tag?  If so,
what is the VLAN number?  What is the name of the physical interface
on which it arrives?  Do you want that VLAN tag to be removed?  Do you
want another VLAN tag to be added?  Do you want it bridged to another
interface?  If so, which interface?  When it comes out that other
interface, should it have a VLAN tag?  If so, with what VLAN number?

You've mentioned that you're using bridging, then you say you want
switching, then you give a specific example of a switch you want
FreeBSD to act like.  FreeBSD will not act like that switch.  You may
be able to accomplish the same thing, but the performance,
configuration and operation will be different.  If you want FreeBSD to
act exactly like a Cisco switch with a few lines in rc.conf, then you
should probably stop now, FreeBSD is the wrong tool for the job.

If, however, you can be very specific about what it is you want to do,
instead of just repeating the same things about switches and VLANs,
then we might be able to help you do it with FreeBSD.  We'd all very
much like to, but what you're trying to do is not clear.  Forget all
about what the VLAN interfaces are named, forget all about IP
addresses, and tell us what you want to do.

Thanks,
Juli.
___
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: Modifying "arp" command

[Juli Mallett]

Hi Rajneesh,

On Sat, Dec 31, 2011 at 00:31, Rajneesh Kumar  wrote:
> Hi Juli
>
> Thank You for the prompt reply. But I can't find any directory called
> src/usr.sbin/arp
> Also If I am trying to find the file arp.c using find command (i.e., find /
> -name arp.c), its unable to locate any such file.

It isn't in the kernel.  Do you have anything other than the kernel
checked out?  What version of the source tree do you have checked out?
 How did you check it out?

If you want just the arp command from head, you can do something like this:

svn co http://svn.freebsd.org/base/head/usr.sbin/arp

Then the arp sources will be in the arp subdirectory of your current
directory.  Beware that "make install" won't work in this case, as the
variable BINDIR (the executable into which the binary is installed) is
set up usr.sbin/Makefile.inc.  You can either run your modified arp
binary out of your current directory, install it by hand (copying it
over your existing one) or set BINDIR when doing make install, like
"sudo make install BINDIR=/usr/sbin", for example.

Thanks,
Juli.
___
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: Modifying "arp" command

[Juli Mallett]

Hi Rajneesh,

On Sat, Dec 31, 2011 at 00:12, Rajneesh Kumar  wrote:
> I want to modify the "arp" command in FreeBSD. Precisely I don't want it to
> display the time to expire for every entry. Which file should I edit? Will
> it be effective after kernel compilation and re-build?

The arp command is part of userland, not the kernel.  It is a utility
which runs from user-space and can be run from any running system.
Unless your file system is embedded in your kernel, you shouldn't need
to rebuild your kernel.

For arp, since it is in /usr/sbin, the source is in src/usr.sbin/arp.
The file arp.c is the one you want to edit.  So check our that
directory, or go to it in your existing checkout, and edit arp.c.  Run
"make" to rebuild the arp binary.  If you want to install it on your
running system, do "make install" — you have to do that as root, so
use sudo or su first.

You may want to send your changes to the list after you make them, as
although this is a very simple change, it may be something the wider
developer community would be interested, and could conceivably be
committed.  For example, if you added a new command line option to
hide expiration times, or to make the output more machine-readable, or
something of that sort, that might be of general utility.

Good luck!

Juli.
___
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: Firewall Profiling.

[Juli Mallett]

2011/12/27 Lev Serebryakov :
> Hello, Luigi.
> You wrote 27 декабря 2011 г., 18:26:00:
>
>> plans, yes - not sure how long it will take. I have compiled
>> ipfw+dummynet as a standalone module (outside the kernel)
>> but have not yet hooked the code to netmap to figure out how fast
>> it can run.
>  I still don't understand why it should be faster than "normal" way,
> as it is essentially same (ipfw + dummynet) code + some additional
> context switches for netmap (to userland and back).
>  What does netmap shave off from packet processing in this particular
> case, to compensate context switches? I

Reloading of mbufs into DMA descriptors?  mbuf allocator overhead
itself?  Interrupts.  Context switches under constant heavy load.
Some indirection in the network stack.
___
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: Compiling only "network" part of the kernel

[Juli Mallett]

On Mon, Dec 26, 2011 at 22:23, Rajneesh Kumar  wrote:
> During my development, I want to check if my modules compile successfully
> or not. I am only changing the ARP portion and whenever I compile my
> kernel, it takes around 20mins and compiles all different modules also.
> I just want to compile and check whether my ARP modules, which I have
> changed, compile fine or not. How to do it?

You need to tell us what process you are using so we can give an
example that best fits your existing workflow.  There are ways we
suggest for users and ways developers use, and it would be a shame to
give you irrelevant suggestions.

If you're using "make buildkernel" then you can add -DNO_CLEAN (or
perhaps it's -DNOCLEAN) to avoid cleaning out the object directory
first.  This will keep dependencies up-to-date for you, and only
rebuild what's necessary.

What may be better, if you don't need a cross-compiler, is to do the
kernel configuration by hand.  So you might do something like:

cd /path/to/src/sys/amd64/conf
config GENERIC
cd ../compile/GENERIC
make depend
make kernel

And then when you make changes you can just do "make kernel".  If you
make a change that requires rerunning config(8), it will tell you to
do "make cleandepend && make depend" or something like that first, to
fix header and option dependencies that may not exist with your new
configuration.

Hopefully one of those two things will help, as anything else you
might be doing is probably based on one of those processes, but if not
you should let us know what you're doing now.

Thanks,
Juli.
___
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: vlan without ip address

[Juli Mallett]

gt;>>>
>>>>>
>>>>> On Sun, Dec 18, 2011 at 10:01 AM, saeedeh motlagh
>>>>>   wrote:
>>>>>
>>>>>> i have 3 freebsd system: 0.28 , 0.25 and 0.12 which 28 is assumed to be
>>>>>> switch here. one interface of 28 is connected to 25 and the other
>>>>>> interface
>>>>>> of 28 is connected to 12. as mentioned below, i've defined two vlan10
>>>>>> and
>>>>>> 11 with the same vlan id on the 28 and bridge them.
>>>>>> now i can't ping 0.25 from 0.12. what's wrong here? should i define
>>>>>> vlan10
>>>>>> on 12 and 25?
>>>>>> please tell me if i'm misunderstanding.
>>>>>> this is the ifconfig for 0.28:
>>>>>> vlan10: flags=8943
>>>>>> metric 0
>>>>>> mtu 1500
>>>>>>    options=3
>>>>>>    ether 00:27:0e:03:4b:2f
>>>>>>    media: Ethernet autoselect (1000baseT)
>>>>>>    status: active
>>>>>>    vlan: 10 parent interface: gbeth0
>>>>>> vlan11: flags=8943
>>>>>> metric 0
>>>>>> mtu 1500
>>>>>>    options=100
>>>>>>    ether 00:30:4f:63:5a:bc
>>>>>>    media: Ethernet autoselect (none)
>>>>>>    status: active
>>>>>>    vlan: 10 parent interface: msk0
>>>>>> bridge0: flags=8843  metric
>>>>>> 0 mtu
>>>>>> 1500
>>>>>>    ether d6:c4:f6:0f:5e:4f
>>>>>>    id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
>>>>>>    maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
>>>>>>    root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
>>>>>>    member: vlan11 flags=143
>>>>>>            ifmaxaddr 0 port 6 priority 128 path cost 55
>>>>>>    member: vlan10 flags=143
>>>>>>            ifmaxaddr 0 port 5 priority 128 path cost 2
>>>>>>
>>>>>>
>>>>>> On Sat, Dec 17, 2011 at 8:47 PM, Alireza Torabi
>>>>>> **wrote:
>>>>>>
>>>>>>  َAlso it's a good idea to to attach a ifconfig output.
>>>>>>>
>>>>>>> On 12/17/11, saeedeh 
>>>>>>> motlagh>
>>>>>>>  wrote:
>>>>>>>
>>>>>>>> when i do that, the vlan is defined but from a system in a vlan, i
>>>>>>>> can't
>>>>>>>> ping the other one which is in the same vlan. so i think that the
>>>>>>>> vlan is
>>>>>>>> not working. am i right?
>>>>>>>>
>>>>>>>> On Sat, Dec 17, 2011 at 1:15 PM, Juli Mallett
>>>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>  You probably just need to do ifconfig vlanxxx up instead of
>>>>>>>>> assigning an
>>>>>>>>> IP.
>>>>>>>>>
>>>>>>>>> On Sat, Dec 17, 2011 at 00:08, saeedeh motlagh
>>>>>>>>>   wrote:
>>>>>>>>>
>>>>>>>>>> hi every body
>>>>>>>>>>
>>>>>>>>>> i wanna configure a freebsd box as a switch. in order to do that,
>>>>>>>>>> i
>>>>>>>>>>
>>>>>>>>> bridged
>>>>>>>>>
>>>>>>>>>> all my interfaces to have switching and it works fine. after that
>>>>>>>>>> i
>>>>>>>>>>
>>>>>>>>> want
>>>>>>>
>>>>>>>> to
>>>>>>>>>
>>>>>>>>>> have vlans on it. as you know, in a real switch, a vlan is
>>>>>>>>>> configured
>>>>>>>>>>
>>>>>>>>> just
>>>>>>>>>
>>>>>>>>>> by assigning a port to it without any additional configuration and
>>>>>>>>>>
>>>>>>>>> vlans
>>>>>>>
>>>>>>>>  are submitted just by name. but in freebsd a vlan just works when
>>>>>>>>>> it
>>>>>>>>>>
>>>>>>>>> has
>>>>>>>
>>>>>>>> an
>>>>>>>>>
>>>>>>>>>> ip address (i think). when i define vlan121 on two freebsd systems
>>>>>>>>>>
>>>>>>>>> with
>>>>>>>
>>>>>>>> ip
>>>>>>>>>
>>>>>>>>>> address it works fine but without ip address i don't know how it
>>>>>>>>>>
>>>>>>>>> should
>>>>>>>
>>>>>>>> be
>>>>>>>>>
>>>>>>>>>> worked.
>>>>>>>>>>
>>>>>>>>>> can sombody tell me if it is possible to simulate vlans in freebsd
>>>>>>>>>> as
>>>>>>>>>>
>>>>>>>>> they
>>>>>>>>>
>>>>>>>>>> are in a real switch? i mean can we have vlans without ip
>>>>>>>>>> addresses
>>>>>>>>>> which
>>>>>>>>>> works fine? maybe some kind of vlan which works by MAc address. is
>>>>>>>>>> it
>>>>>>>>>> possible?
>>>>>>>>>> it's so necessary for me to do that:(
>>>>>>>>>>
>>>>>>>>>> yours,
>>>>>>>>>> motlagh
>>>>>>>>>> __**_
>>>>>>>>>> freebsd-net@freebsd.org mailing list
>>>>>>>>>> http://lists.freebsd.org/**mailman/listinfo/freebsd-net<http://lists.freebsd.org/mailman/listinfo/freebsd-net>
>>>>>>>>>> To unsubscribe, send any mail to
>>>>>>>>>> "freebsd-net-unsubscribe@**freebsd.org
>>>>>>>>>>
>>>>>>>>> "
>>>>>>>
>>>>>>>>
>>>>>>>>>  __**_
>>>>>>>> freebsd-net@freebsd.org mailing list
>>>>>>>> http://lists.freebsd.org/**mailman/listinfo/freebsd-net<http://lists.freebsd.org/mailman/listinfo/freebsd-net>
>>>>>>>> To unsubscribe, send any mail to
>>>>>>>> "freebsd-net-unsubscribe@**freebsd.org
>>>>>>>> "
>>>>>>>>
>>>>>>>>
>>>>>>>  __**_
>>>>>> freebsd-net@freebsd.org mailing list
>>>>>> http://lists.freebsd.org/**mailman/listinfo/freebsd-net<http://lists.freebsd.org/mailman/listinfo/freebsd-net>
>>>>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@**
>>>>>> freebsd.org "
>>>>>>
>>>>>
>>>>
>>>>  __**_
>>> freebsd-net@freebsd.org mailing list
>>> http://lists.freebsd.org/**mailman/listinfo/freebsd-net<http://lists.freebsd.org/mailman/listinfo/freebsd-net>
>>> To unsubscribe, send any mail to 
>>> "freebsd-net-unsubscribe@**freebsd.org
>>> "
>>>
>>
>>
> ___
> 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"
___
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: confused with if_baudrate

[Juli Mallett]

On Thu, Nov 17, 2011 at 13:12, Maksim Yevmenkin
 wrote:
> hello,
>
> i'm a little bit confused about if_baudrate. from system headers
>
> #define if_baudrate     if_data.ifi_baudrate
>
> and
>
> u_long  ifi_baudrate;           /* linespeed */
>
> so, i'm taking this as if_baudrate really should be an interface line
> speed in megabits per second. am i correct? if so, then it appears
> that at least some drivers lie about true line speed. for example from
> ixgbe(4)
>
>        ifp->if_baudrate = 10;
>
> it looks like its order of magnitude lower (i.e. 1 gigabit per second
> instead of 10 gigabits per second). am i missing something here or its
> just a typo?

ixgbe's developer is excessively concerned about overflow on 32-bit
hosts (and unwilling to correct it under a preprocessor conditional),
unlike several of the other 10GbE driver developers, although I think
one 10GbE driver opts to omit if_baudrate entirely.

Thanks,
Juli.
___
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: ether_demux does not handle frames with embedded vlan tags

[Juli Mallett]

On Wed, Oct 19, 2011 at 14:47, Ryan Stone  wrote:
> On Wed, Oct 19, 2011 at 3:30 PM, Juli Mallett  wrote:
>> Why should the requirements for the Netgraph path be any different to
>> the non-Netgraph path?  If drivers must ensure that frames that reach
>> ether_demux have had their VLAN tags stripped, so should Netgraph
>> things that act like drivers.  So why don't you move that logic into
>> ether_demux from the ether_input path, or have Netgraph use the
>> ether_input path?
>
> Netgraph can't use the ether_input path because ether_input passes the
> packet to the lower hook.  It also passes the packet to things like
> carp or if_bridge if necessary.  I'm not sure whether it is intended
> behaviour that the upper hook bypasses carp and if_bridge.
>
> if_bridge also depends on the vlan stripping behaviour, so vlan
> stripping cannot be moved to ether_demux without re-implementing it in
> bridge_input.

This seems like a good argument for a flag like M_SKIPFIREWALL (or
whatever it's called these days) that says that the packet was
injected by an upper layer (in general, not just netgraph), which in
the netgraph case could skip the lower filter.  That would be
considerably more consistent with how other Ethernet devices work,
which would be an improvement over the current short-circuit to
ether_demux.
___
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: ether_demux does not handle frames with embedded vlan tags

[Juli Mallett]

On Wed, Oct 19, 2011 at 07:36, Ryan Stone  wrote:
> 2011/10/19  :
>> This may be a wrong configuration or QinQ: packet may have M_VLAN tag is
>> set and still vlan-tagged (ether_type = VLAN)
>
> It is not QinQ in my case.  The interface that the upper hook exports
> is that you send it a valid ethernet frame and it passes that frame up
> the stack.  A vlan-tagged frame is a valid frame so I don't see why it
> should not be handled correctly.

Why should the requirements for the Netgraph path be any different to
the non-Netgraph path?  If drivers must ensure that frames that reach
ether_demux have had their VLAN tags stripped, so should Netgraph
things that act like drivers.  So why don't you move that logic into
ether_demux from the ether_input path, or have Netgraph use the
ether_input path?
___
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: Question about GPIO bitbang MII

[Juli Mallett]

On Thu, Oct 6, 2011 at 19:34, dave jones  wrote:
> Hi,
>
> Does FreeBSD have gpio bitbang api for MII? If not, any driver in tree using
> gpio-bitbang mii that I can refer to? Thanks.
> It seems like OpenBSD, NetBSD and Linux have added support to gpio bitbang 
> mii,
> and it's useful for porting embedded devices.

FreeBSD has a GPIO API and MACs can use whatever mechanism they like
to attach MII (or similar, as in the case of devices like switches
that sort of use MDIO but aren't exactly like Ethernet PHYs on an MII
bus.)

Or do you not want to do this within a driver for a particular MAC,
but just make the MII bus available for poking and prodding to
userland, backed by GPIO?

Can you give an example of an OpenBSD driver that uses the API you're
talking about?  I've worked with some drivers for FreeBSD which have
used GPIO bit-banging to expose an MII bus, but adding the abstraction
of the GPIO layer hasn't typically been worthwhile for those as
they're an SoC with dedicated GPIO for networking devices or similar.

Thanks,
Juli.
___
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: which 10GE cards are supported by FreeBSD ?

[Juli Mallett]

On Sat, Sep 24, 2011 at 13:52, Luigi Rizzo  wrote:
> apart from the typo ("know know") yes the email contained three
> serious questions, two of which (third party drivers and shops
> which carry the card) i cannot answer looking at the tree.
>
> On top of this, some in-tree drivers may be stale, broken, redundant
> (say ixgb vs ixgbe), and so on.  And not all hardware can do line
> rate -- not even at 1G, let alone 10G, so it would be good to know
> also some first hand information on performance.

ixgb vs. ixgbe is not a stale/redundant issue.  ixgb only supports the
82597, which you'll find is not supported by ixgbe.

I think you'll have a hard time getting reliable performance
information.  There's a lot of smoke and mirrors about performance, as
you point out.  It has also been my experience that many 10g devices
cannot reliably do 1g line rate with minimal packet sizes.  I don't
fully understand why this is, but most people who I've seen give
performance numbers for FreeBSD are looking at bulk transmit, which is
of course not (necessarily) what you care about for netmap.  I've yet
to hear from anyone who can name a 10G NIC one can buy that can do
line rate with minimal packet sizes.  Solarflare boasts about lower
latency, so perhaps they'll have a better story in that area.

> The goal of the question was also to get -- and have on the archives,
> for the future -- informed feedback ("i have card X and works/does
> not work with driver Y and performance is Z", see Vlad's reply).

A wiki page would be nice.

> wow, that's a lot of information :)
>
> seriously though:
> i have Intel and know it works reasonably well and have published
> detailed data on that on the netmap page.  Vlad has replied about
> Myricom.  I know that Chelsio has a card and supports it.  But I
> have no first-hand information about the others: for instance, do
> we support Marvell ? which driver ?  What about broadcom ?  Any
> other makers&drivers for 10G on FreeBSD ?

Broadcom is bxe.  It's actually not as trivial to grep for 10G NICs as
implied, since some drivers have silly bugs, like ixgbe which sets
if_baudrate to '10' (i.e. 1 000 000 000).
___
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: em driver problem on vmware

[Juli Mallett]

On Fri, Oct 29, 2010 at 17:07, Ricky  Charlet  wrote:
> Howdy,
>        I have freebsd80-release with an upgraded em0 driver from freebsd8.1 
> (and an appropriate touch of if_var.h). I'm running an amd64 on a  vmware vm. 
>  And I see this in dmesg:
>
> cut-
> em0:  port 0x2000-203f mem 
> 0xd894-0xd895, 0xd890-0xd890 irq 18 at device 0.0 on pci2
> em0: Memory Access and/or Bus Master bits were not set
> em0: [FILTER]
> em0: Ethernet address: 00:0c:29:57:d7:7f
> paste
>
>        But, on the other hand, has anyone seen the new em driver 
> working/failing on a vmware vm?

"Memory Access and/or Bus Master bits were not set" is not a fatal
error, it is correctable, indeed that is printed out when it is
corrected; that is not something to worry about in and of itself as
such, are you actually having a problem or just concerned because you
saw that in dmesg?
___
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: mbuf changes

[Juli Mallett]

On Sat, Oct 2, 2010 at 12:07, Rui Paulo  wrote:
> On 2 Oct 2010, at 16:29, Robert Watson wrote:
>> On Thu, 30 Sep 2010, Julian Elischer wrote:
>>> On 9/30/10 10:49 AM, Ryan Stone wrote:
 It's not a big thing but it would be nice to replace the m_next and 
 m_nextpkt fields with queue.h macros.
>>> funny, I've never even thought of that..
>>
>> I have, and it's a massive change touching code all over the kernel in vast 
>> quantities.  While in principle it's a good idea (consistently avoid 
>> hand-crafted linked lists), it's something I'd discourage on the basis that 
>> it probably won't significant reduce the kernel bug count, but will make it 
>> even harder for vendors with large local changes to the network stack to 
>> keep up.
>
> I think it could also increase the kernel bug count. Unfortunately, we can't 
> do this incrementally.

Can't we?  What about a union, so that we can gradually convert things
but keep ABI and API compatibility?  I mean, as long as we use the
right queue.h type, anyway, it should be consistent?  STAILQ,
presumably.
___
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: Dual-rate transceivers with ixgbe?

[Juli Mallett]

On Thu, Jun 10, 2010 at 12:04, Alexander Sack  wrote:
> However, would it be possible to please make this a kenv tunable in
> the driver?  Its kinda stupid I have to recompile to add a SFP.  It
> can certainly be an unsupported feature by you.

This is a good idea, but asking Jack to commit something that goes
against Intel's wishes and which he's not going to support is probably
a losing strategy.  Whether he minds someone else committing might be
another story :)

One thing that the base driver probably ought to do is not fail in
attach if there's an unrecognized SFP+ module.  Since we get
interrupts on module change (although this doesn't seem to always work
*entirely* right in the stock sources, mostly wrt stored values of
AUTOC and the like) it should be possible to bring the interface up
with the unsupported (and disabled) SFP+ module and do the SFP+ module
probing we already do on hot-swap.

> Patch attached.  Tested with CURRENT driver on a 7.2-amd64-release
> machine.  If you set the tunable to 1, ixgbe loads without issue.  If
> you leave it to zero (default), it will not attach to unsupported
> SFPs.

If you're going to do this, you ought to support SFP as well as SFP+
modules which requires a few more changes.  But not very many :)
Although some SFP modules seem to return something for the
comp_codes_10g read, which makes deciding which SFI mode to configure
non-trivial, short of providing an actual vendor/model switch.

Thanks,
Juli.
___
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: Dual-rate transceivers with ixgbe?

[Juli Mallett]

On Wed, Jun 9, 2010 at 19:56, Alexander Sack  wrote:
> $ ifconfig ix1
> ix1: flags=8802 metric 0 mtu 1500

You need to bring the interface up in order for the SFP configuration to occur.

> # ifconfig ix1 down
> # ifconfig ix1 up
> # ifconfig ix1
> ix1: flags=8843 metric 0 mtu 1500
___
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: Dual-rate transceivers with ixgbe?

[Juli Mallett]

On Wed, May 19, 2010 at 00:26, Jack Vogel  wrote:
> Hmmm, this is odd, I'm sure that was tested by my validation engineer.
> Tell me what the hardware looks like, ie what the 1G link partner is
> and I'll have him check into it... it SHOULD work.

It's plugged in to an Extreme Networks gigabit switch with Finisar SFP
transceivers.  The Intel NIC is populated with an Intel-branded
Finisar dual-rate SFP+ transceiver, model #FTLX8571D3BCV.

Here's pciconf -lv:
i...@pci0:8:0:0:class=0x02 card=0x00038086 chip=0x10fb8086 rev=0x01 
hdr=0x00
vendor = 'Intel Corporation'
class  = network
subclass   = ethernet
i...@pci0:8:0:1:class=0x02 card=0x00038086 chip=0x10fb8086 rev=0x01 
hdr=0x00
vendor = 'Intel Corporation'
class  = network
subclass   = ethernet

Is there anything it would help for me to instrument in the driver?

> You could just ask me you know :)

I think E-Mails from me are getting caught in your spam filter unless
they go through a list :(

Thanks!
Juli.
___
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"

Dual-rate transceivers with ixgbe?

[Juli Mallett]

Hey all,

Has anyone out there been able to get link using a dual-rate
transceiver at 1gig with the ixgbe driver in FreeBSD?  I have an SFP+
NIC and an Intel-branded dual-rate transceiver but it will only get
link at 10gig.

I used the latest driver from FreeBSD trunk backported (which IIRC
didn't take any significant changes; jfv@ does a good job of keeping
the drivers working across branches) to 7.x for my testing.  A
similarly-versioned Linux driver (with only trivial and mostly
cosmetic differences in the hardware code outside of the main driver)
worked at 1gig just fine.  All testing was done with switches rather
than host-to-host connections.

It seems like someone else must have tried this and it seems like
there must just be some trivial difference in card initialization
between FreeBSD and Linux, so I thought I'd ask publicly to see if
anyone had patches.  I instrumented the code extensively but so far
have come up empty-handed.

Thanks,
Juli.
___
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: sscanf in kernel

[Juli Mallett]

On Wed, Mar 17, 2010 at 13:39, igeek  wrote:
> On Mar 17, 2010, at 2:12 PM, serena zanetta wrote:
>> Hi,
>> I need to convert an ascii string in its corresponding hex version (the
>> same
>> as sscanf(str,"%02x%02x...",...) does) in the kernel.

FreeBSD has sscanf in the kernel.  See .  That said,
sscanf is pretty evil — are you sure it's what you want?  Are you sure
you need to parse it in the kernel instead of in userland?

> sscanf() has a kernel version declared in kernel.h.
> http://www.gelato.unsw.edu.au/lxr/source/include/linux/kernel.h#L196

I believe you are confused.  FreeBSD is not Linux.
___
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: tap dhcp

[Juli Mallett]

On Mon, Sep 28, 2009 at 14:50, Adam Vande More  wrote:
> Should I recieve a response?  From tap(4), and other examples my
> understanding is yes, but that is not what I'm seeing in practice.  Forgive
> my ignorance, but wouldn't bridge0 pass a response back to tap0?

tap(4) takes the network interface layer of the kernel and allows a
user process to interact with it directly.  If I am writing, for
example, a program to tunnel traffic over IRC channels (or any other
broadcast medium; tun(4) is more appropriate for point-to-point links)
I can have my IRC client create a tap(4) device.  Then, when I try to
ping a system through the tap(4) interface, the networking layer takes
the packet and sends it up to my IRC client.  My IRC client then
(let's say) base64 encodes it and spews it into the channel.  Another
IRC client in that channel with the same code running on it sees that
I've sent a packet and base64 decodes it and sends it down into their
kernel's tap(4) interface.  Then that comes through the packet input
codepath — the kernel sees that data as though it were a packet come
in off the wire.  Packets that go out on a tap(4), e.g. via ping, are
sent to a userland process.  Packets can only come in (in the sense of
the input path of the network stack) on a tap(4) via that same channel
with a userland process.

> My goal is essentially clone my network connection recieving two DHCP leases
> to the same box.  Also I am aware of ifconfig alias, but that didn't seem up
> to the task.

There are things you can do with netgraph, but they're not very good.
Do you actually want both interfaces to see the same traffic, or do
you want to create two virtual interfaces attached to one physical?
If you provide a clear description of your needs, somebody else can
probably help you.  I'm out of touch on the latest and greatest way to
do this with FreeBSD, sorry.

Juli.
___
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: tap dhcp

[Juli Mallett]

On Mon, Sep 28, 2009 at 13:21, Adam Vande More  wrote:
> Am I doing something wrong here?

That depends on what you're expecting to happen.  What do you think
tap(4) does and what are you trying to accomplish with using it?
Interface bridging controls what happens on packet ingress — when a
packet comes in on one side of the bridge it is forwarded out the
other.  When dhclient(8) sends out a DHCPDISCOVER on tap0, that goes
through the interface output routine.  tap(4) works such that then
would go to a user-space process reading from tap0 and then that
process would forward it on to somewhere else where eventually it
might find a DHCP server.  If it does, the DHCP reply would come back,
that user-space process would inject it into the kernel and the
bridging code would pass it out em0.

> kldload if_tap if_bridge
> sysctl net.link.tap.user_open=1
> ifconfig tap0 create
> ifconfig bridge create
> ifconfig bridge0 addm tap0 addm em0
>
> it# dhclient tap0
> DHCPDISCOVER on tap0 to 255.255.255.255 port 67 interval 6
> DHCPDISCOVER on tap0 to 255.255.255.255 port 67 interval 6
> DHCPDISCOVER on tap0 to 255.255.255.255 port 67 interval 13
> DHCPDISCOVER on tap0 to 255.255.255.255 port 67 interval 18
> DHCPDISCOVER on tap0 to 255.255.255.255 port 67 interval 18
> No DHCPOFFERS received.
> No working leases in persistent database - sleeping.
>
> Although dhclient em0 works as expected.
>
> FreeBSD it.digitecinc.net 8.0-BETA4 FreeBSD 8.0-BETA4 #2: Mon Sep  7
> 11:26:25 CDT 2009
> vandemo...@it.digitecinc.net:/usr/obj/usr/src/sys/GENERIC
> i386
>
> Repost from questions@ several days ago.
>
> Thanks,
>
> --
> Adam Vande More
> ___
> 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"
>
___
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"

bge(4) ASF problem report...

[Juli Mallett]

Hey there,

On my HP DL360 G4 with bge interfaces identified as "NC7782 Gigabit
Server Adapter, ASIC rev. 0x2100", I find that having ASF enabled
results in a total system freeze.  Is anyone else running this
hardware on either 7.x or 8-CURRENT?  If so, I'd love to hear whether
hw.bge.allow_asf=1 (the default on 8-CURRENT) is problematic for you
and whether setting it to 0 instead fixes it.  I'd like to disallow
ASF by device ID if this reliably affects this hardware, but this is
the only DL360 G4 I've got.

Any objections?  Or is there anyone who cares about bge who would be
interested in trying to figure out what the actual problem is?  Note
that I haven't tried enabling the iLO shared network port stuff, so I
don't know if that would have any unfortunate interactions with ASF
support or lack thereof.

Thanks,
Juli.
___
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: Removal of netns - politically correct version

[Juli Mallett]

* De: Mark Murray <[EMAIL PROTECTED]> [ Data: 2003-03-05 ]
[ Subjecte: Re: Removal of netns - politically correct version ]
> Terry Lambert writes:
> > Peter Wemm wrote:
> > > Terry Lambert wrote:
> > > > Is there a compelling reason for removing this working code to
> > > > the Attic?
> > > 
> > > Terry: will you please check your facts?  It takes around 30 seconds
> > > to find out that it doesn't even compile.
> > 
> > [ ... lots of trivial to fix warnings and errors ... ]
> > 
> > 
> > Tell you what, I'll fix these and post a patch.  Will that make you
> > guys happy?
> > 
> > This crap is *s* trivial to fix, it's easier to fix than
> > to watch you guys bitch about it not being fixable.
> 
> Will it be runnable (as in tested), rather than a compile-only fix?

compile-only would be a good state to leave the code in the attic.
-- 
juli mallett. email: [EMAIL PROTECTED]; aim: bsdflata; efnet: juli;

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: Removal of netns - politically correct version

[Juli Mallett]

* De: Terry Lambert <[EMAIL PROTECTED]> [ Data: 2003-03-05 ]
[ Subjecte: Re: Removal of netns - politically correct version ]
> On the other hand, there's no compelling reason to dike it out,
> if it can be made to work.  I would argue that ISA support is
> more or less just as obsolete, as is 486 support, as is the F00F
> bug workaround, as is ... a lot of code that's still there.

I have a 486, lots of people have 486 PC 104 boards.  I have a lot
of ISA stuff.  VLSI support would be equally obsolete.  So would
support for a Sequent SMP 386.  We don't support them.  We have at
least one feature you demonstate over and over needs moved to the
attic.
-- 
juli mallett. email: [EMAIL PROTECTED]; aim: bsdflata; efnet: juli;

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: Removal of netns - politically correct version

[Juli Mallett]

* De: Mark Linimon <[EMAIL PROTECTED]> [ Data: 2003-03-04 ]
[ Subjecte: Re: Removal of netns - politically correct version ]
> On Tue, 4 Mar 2003, Terry Lambert wrote:
> > Tell you what, I'll fix these and post a patch.  Will that make you
> > guys happy?
> 
> Yes, as will anything else that cuts down on the metadiscussions and
> increases the quality of the codebase.

No, it screws up the quality of the codebase if it cannot be tested and
used every day, and I doubt Terry will be doing real testing.

HOWEVER, I am willing to keep netns working if someone can provide a pure
XNS with IP-over-XNS provider.  Playing around using multiple FreeBSD boxen
with a possibly broken but interoperable implementation is also out of the
question, as nobody uses it.  For things that people actually use, it's OK
as prototyping fixes and getting them in tree, and then the users can find
where it's broken later.
-- 
juli mallett. email: [EMAIL PROTECTED]; aim: bsdflata; efnet: juli;

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: Removal of netns - politically correct version

[Juli Mallett]

* De: Terry Lambert <[EMAIL PROTECTED]> [ Data: 2003-03-04 ]
[ Subjecte: Re: Removal of netns - politically correct version ]
> Peter Wemm wrote:
> > Terry Lambert wrote:
> > > Is there a compelling reason for removing this working code to
> > > the Attic?
> > 
> > Terry: will you please check your facts?  It takes around 30 seconds
> > to find out that it doesn't even compile.
> 
> [ ... lots of trivial to fix warnings and errors ... ]
> 
> 
> Tell you what, I'll fix these and post a patch.  Will that make you
> guys happy?
> 
> This crap is *s* trivial to fix, it's easier to fix than
> to watch you guys bitch about it not being fixable.

Terry, watch your language.

And then find me a site running XNS that expects to be running a current
version of FreeBSD, or ideally someone I could peer an XNS system with if
I were to take up maintainership of it?

You have until the code is gone from CVS, which hopefully will be very soon.

Thanx,
juli.

PS: I might be interested in getting it out of the attic if you could find me
a good place for XNS-only connectivity, with IP-over-XNS of some sort so
I could still IRC.
-- 
juli mallett. email: [EMAIL PROTECTED]; aim: bsdflata; efnet: juli;

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: support of iso networking

[Juli Mallett]

* De: Petri Helenius <[EMAIL PROTECTED]> [ Data: 2003-02-19 ]
[ Subjecte: Re: support of iso networking ]
> > On the other hand the NetBSD folks don't see it as dead weight
> > and systems that may need to talk with core routers that use
> > IS-IS end up on other platforms.
> > 
> > Perhaps this is why Arbor uses NetBSD.
> > 
> 
> It should be noted that hardly anything qualifies as "dead weight" on operating
> system that runs on your toaster, car stereo and washing machine not to mention
> old computers.
> 
> There are different tools for different tasks and the quest for "there should be 
>only one" 
> is futile.
> 
> The most significant router vendor using an open source OS is based on 
> FreeBSD anyway so there should be no reason for shame.

Any company which is going to have to modify an operating system to run
on their routers who ignores an operating system with a reputable network
stack merely because it lacks in-tree support for a particular protocol
isn't worth hte money.  There are plenty of good ones out there who, in
addition to maintaining large amounts of local support diffs for FreeBSD,
also maintain netccitt or netiso or netns or whatever suits the market
they're selling for.  Hell, if they turn it down simply for lack of a
network stack, then they probably simply aren't willing to do anything
but minor maintainence to "keep it running" so what's the point for us?

They're probably making at least a few of their sales for having it around.

Heck, there are probably more people attached to FreeBSD on pc98 than to
netiso or   I'm willing to say that because hey look it's been at least
moderately well maintained, and kept up with most moves forward, except
for the wd(4) stuff, though I think I heard someone talking about hiding
wd, simply to get people to actually find and fix the bugs in ad on pc98.

In short: Yeah, exactly :)

juli, who's afraid her rants may be the equal of someone else's far too soon.
-- 
Juli Mallett <[EMAIL PROTECTED]> - AIM: BSDFlata -- IRC: juli on EFnet
OpenDarwin, Mono, FreeBSD Developer - ircd-hybrid Developer, EFnet addict
FreeBSD on MIPS-Anything on FreeBSD - Never trust an ELF, COFF or Mach-O!

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: Intel PRO/100 S

[Juli Mallett]

* De: Marc Ernst Eddy van Woerkom <[EMAIL PROTECTED]> [ Data: 
2002-10-01 ]
[ Subjecte: Intel PRO/100 S ]
> Hi,
> 
> yesterday I bought a network card to connect a second PC 
> to my old machine.
> They had only one type of card in the store so I bought it anyway, 
> despite its rather high price of 37 Euro.
> 
> Today I took a closer look.
> It is an Intel PRO/100 S board packaged in 
> plastic pack, without docs.
> It comes with 3 wire cable labeled
> "BIZLINK" and has "TRIPLE DES" on a label.
> 
> As far as I can tell from a bit of Google
> research, it features hardware encryprtion/decryption.
> 
> Questions:
> - Can I use it under FreeBSD?

Yes, as an fxp(4).

> - Can I make use of that hardware acceleration?

Not under FreeBSD.

> - What is the 3 wire cable for?

For WOL.

> 
> Regards,
> Marc
> 
> 
> 
>  
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message

-- 
Juli Mallett <[EMAIL PROTECTED]>   | FreeBSD: The Power To Serve
Will break world for fulltime employment. | finger [EMAIL PROTECTED]
http://people.FreeBSD.org/~jmallett/  | Support my FreeBSD hacking!

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: programatically list all local IP addresses ?

[Juli Mallett]

* De: Alex Rousskov <[EMAIL PROTECTED]> [ Data: 2002-07-18 ]
[ Subjecte: Re: programatically list all local IP addresses ? ]
> On Thu, 18 Jul 2002, Chuck T. wrote:
> 
> > Yes portablity is a concern, unfortunately my program will
> > probably be used on Linux more than FreeBSD, sigh.  I starting to
> > read about ioctl() and SIOCGIFADDR which appears to be portable
> > (and a pain).
> 
> We had to write portable local address detection for Web Polygraph. In
> my experience, ioctl/SIOCGIFADDR is not portable at all and is a lot
> of pain. Linux uses them differently from FreeBSD, and the exact
> interface/behavior is often OS-version specific (e.g., for Solaris
> IIRC).
> 
> Looking at existing code helps. I would suggest using getifaddrs(3)
> where available (./configure can detect that, of course) and delve
> into ioctl() and other OS-specific methods where getifaddrs(3) is not
> supported. Stockpile some pain relieve medication first.

Using a library which has these sorts of things abstracted helps.  I believe
this particular case is one covered by libnet or libdnet or whatever it's
called.
-- 
Juli Mallett <[EMAIL PROTECTED]>   | FreeBSD: The Power To Serve
Will break world for fulltime employment. | finger [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: the incredible shrinking socket

[Juli Mallett]

* De: Mike Silbersack <[EMAIL PROTECTED]> [ Data: 2002-07-07 ]
[ Subjecte: Re: the incredible shrinking socket ]
> 
> On Sun, 7 Jul 2002, Alfred Perlstein wrote:
> 
> > Some time ago I noticed that there appeared to be several members
> > of struct socket that were either only used by listen sockets or
> > only used by data sockets.
> >
> > I've taken a stab at unionizing the members and we wind up saving
> > 28 bytes per socket on i386, and probably nearly double that on
> > any 64 bit platform.  That's ~15%, which isn't too shabby.
> 
> Unions are ooogly.  Would it be possible to seperate listen-only
> structures out into a seperate struct instead with a pointer to it?

If you're going to do that why not just end the struct with
char foo[1];

And overlay the unique bits at the end?

Or do we already use storage there?
-- 
Juli Mallett <[EMAIL PROTECTED]>   | FreeBSD: The Power To Serve
Will break world for fulltime employment. | finger [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message