Resending with smaller recipients list… From: Joyner, Eric Sent: Friday, January 20, 2017 3:17 PM To: 'Kevin Bowling' <kevin.bowl...@kev009.com>; freebsd-net@freebsd.org Cc: Scott Long <sco...@netflix.com>; Drew Gallatin <galla...@netflix.com>; Navdeep Parhar <navd...@chelsio.com>; Oded Shanoon <od...@mellanox.com>; h...@freebsd.org; Matthew Macy <mm...@nextbsd.org>; Cramer, Jeb J <jeb.j.cra...@intel.com>; arybc...@freebsd.org; sh...@freebsd.org; Sean Bruno <sbr...@freebsd.org>; George Neville-Neil <g...@freebsd.org> Subject: RE: ethctl
For a specialized requirement, I’d like to be able to view VF information underneath the output for a PF interface. Like what the “ip” utility shows and lets you change when you use the “link” command: mac address, vlan, anti-spoof status, and link status. Iovctl would be okay for configuring these things on VF creation, but I’d like to be able to configure these things quickly from the command line, and without re-creating the VF. That information could be added to ifconfig, but like luigi said, ifconfig is already huge, and I think it would bloat the output more. We could try changing ifconfig to use the ip syntax, where there’s one top level command, but the arguments immediately after concern different areas of operation for Ethernet devices. ip has “link” (for setting L2 settings like link and vlans) and “addr” for ipv4/ipv6 stuff, for example. For a potential common requirement, it would also be nice to be able to poll a driver to see which network interfaces are being spawned from it. Not just for VFs, but it’d be useful for when a PF’s interface name doesn’t match the /dev/pci name, or if a driver does queue splitting to create multiple network interfaces from one physical port. That would a solve an issue for us right now. I’m sure more things will come up from the Intel side. - Eric From: Kevin Bowling [mailto:kevin.bowl...@kev009.com] Sent: Thursday, January 19, 2017 7:58 PM To: freebsd-net@freebsd.org<mailto:freebsd-net@freebsd.org> Cc: Scott Long <sco...@netflix.com<mailto:sco...@netflix.com>>; Drew Gallatin <galla...@netflix.com<mailto:galla...@netflix.com>>; Navdeep Parhar <navd...@chelsio.com<mailto:navd...@chelsio.com>>; Oded Shanoon <od...@mellanox.com<mailto:od...@mellanox.com>>; h...@freebsd.org<mailto:h...@freebsd.org>; Matthew Macy <mm...@nextbsd.org<mailto:mm...@nextbsd.org>>; Cramer, Jeb J <jeb.j.cra...@intel.com<mailto:jeb.j.cra...@intel.com>>; Joyner, Eric <eric.joy...@intel.com<mailto:eric.joy...@intel.com>>; arybc...@freebsd.org<mailto:arybc...@freebsd.org>; sh...@freebsd.org<mailto:sh...@freebsd.org>; Sean Bruno <sbr...@freebsd.org<mailto:sbr...@freebsd.org>>; George Neville-Neil <g...@freebsd.org<mailto:g...@freebsd.org>> Subject: RFC: ethctl Greetings, I'm casting a wide net in cc, try to keep the noise minimal but we need some input from a variety of HW vendors. I have heard from several vendors the need for a NIC configuration tool. Chelsio ships a cxgb/cxgbetool in FreeBSD as one example. There is precedence for some nod toward a basic unified tool in Linux ethtool. From your perspective, 1) What are the common requirements? 2) What are specialized requirements? For instance as a full TCP offload card Chelsio needs things others wont 3) What should it _not_ do? Several of you have experience doing Ethernet driver dev on many platforms so we should attempt to avoid repeating past design mistakes. I expect we can achieve some level of inversion so the device specific code can live close to the driver and plug into the ethctl framework. It should be general enough to add completely new top level commands, so vendors can implement HW specific features. On the other hand, we should attempt to hook into common core for features every NIC provides, with a focus on iflib. I will fund Matt Macy to do the overall design and implementation. Regards, Kevin Bowling, on behalf of Limelight Networks for this effort _______________________________________________ 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"
