at 8:25 PM, Saeed Mahameed wrote:
I don't have any strong feeling against disabling compiler warnings,
but maybe the right thing to do here is to initialize the gaps to the
invalid value instead of pre-initializing the whole thing first and
then setting up the valid values on the 2nd pass.
I d
On Sep 4, 2019, at 4:23 PM, Saeed Mahameed wrote:
some allocations require parameters that should remain valid and
constant across the whole reconfiguration procedure such
params.num_channels, so they must be done inside the lock.
You could always check if those parameters have changed once u
On Mar 21, 2019, at 3:19 PM, Bart Van Assche wrote:
This patch does not change any functionality but makes the code easier
to read.
Cc: Sagi Grimberg
Cc: Christoph Hellwig
Signed-off-by: Bart Van Assche
---
net/core/utils.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff -
On Apr 3, 2018, at 11:27 AM, Michael S. Tsirkin wrote:
I'm not sure why you would need a feature bit. The capability is
controlled via PCI configuration space. If it is present the device
has the capability. If it is not then it does not.
Basically if the PCI configuration space is not present
On Mar 15, 2018, at 11:42 AM, Alexander Duyck wrote:
> From: Alexander Duyck
>
> Hardware-realized virtio_pci devices can implement SR-IOV, so this
> patch enables its use. The device in question is an upcoming Intel
> NIC that implements both a virtio_net PF and virtio_net VFs. These
> are har
On Mar 15, 2018, at 11:41 AM, Alexander Duyck wrote:
> From: Alexander Duyck
>
> This patch adds a common configuration function called
> pci_sriov_configure_simple that will allow for managing VFs on devices
> where the PF is not capable of managing VF resources.
>
> Signed-off-by: Alexander
> On Feb 27, 2018, at 7:35 AM, David Miller wrote:
>
> I don't like these helpers on many different levels.
> So kill off pci_sriov_enable() helper completely, it is unnecessary,
> and rename the disable helper so that it says something meaningful to
> the reader.
Yes. Once pointed out, I com
Alex,
> On Feb 26, 2018, at 7:26 AM, Alexander Duyck
> wrote:
>
> Mark,
>
> In the future please don't put my "Reviewed-by" on a patch that I
> haven't reviewed. I believe I reviewed one of the earlier patches, but
> I hadn't reviewed this version.
I'm very sorry. I completely spaced doing so
> On Feb 22, 2018, at 10:26 AM, Christoph Hellwig wrote:
>
> Can we move this into common code as a a generic_sriov_configure
> helper? Nothing is really virtio specific, and it seems like
> some other drivers could also use it, e.g. ena or nvme.
That seems like a good idea to me, especially if
> On Dec 4, 2017, at 9:35 PM, Shannon Nelson wrote:
>
> Add a few routines to make access to the ipsec registers just a little
> easier, and throw in the beginnings of an initialization.
>
> Signed-off-by: Shannon Nelson
> ---
> drivers/net/ethernet/intel/ixgbe/Makefile | 1 +
> drivers/
> On Nov 2, 2017, at 1:09 AM, Prashant Bhole
> wrote:
>
> Use PATH_MAX instead of hardcoded array size 256
>
> Signed-off-by: Prashant Bhole
> ---
> tools/bpf/bpf_jit_disasm.c | 3 ++-
> tools/bpf/bpftool/jit_disasm.c | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --g
> On Oct 8, 2017, at 7:39 AM, Petr Vorel wrote:
>
> diff --git a/testsuite/tests/ip/route/add_default_route.t
> b/testsuite/tests/ip/route/add_default_route.t
> index e5ea6473..0b566f1f 100755
> --- a/testsuite/tests/ip/route/add_default_route.t
> +++ b/testsuite/tests/ip/route/add_default_route
> On Sep 29, 2017, at 3:22 AM, Jason A. Donenfeld wrote:
>
> Hi guys,
>
> One handy aspect of Netlink is that it's backwards compatible. This
> means that you can run old userspace utilities on new kernels, even if
> the new kernel supports new features and netlink attributes. The wire
> format
> On Sep 27, 2017, at 9:39 AM, Grant Grundler wrote:
>
> On Wed, Sep 27, 2017 at 12:15 AM, Oliver Neukum wrote:
>> Am Dienstag, den 26.09.2017, 08:19 -0700 schrieb Doug Anderson:
>>>
>>> I know that for at least some of the adapters in the CDC Ethernet
>>> blacklist it was claimed that the CDC
> On Jul 23, 2017, at 10:05 AM, Florian Fainelli wrote:
>> +
>> +strncpy(drvinfo->version, HNAE_DRIVER_VERSION,
>> +sizeof(drvinfo->version));
>> +drvinfo->version[sizeof(drvinfo->version) - 1] = '\0';
>
> strlcpy() would probably do that for you.
You need to be careful abou
On Mar 12, 2017, at 7:02 PM, Kees Cook wrote:
> Are there nominations for most comprehensive changelog of the year? :)
> This is awesome.
Especially for a one-liner! Truly comprehensive and completely relevant.
--
Mark Rustad, Networking Division, Intel Corporation
signature.asc
Description:
Zhouyi Zhou wrote:
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index fee1f29..4926d48 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -2173,8 +2173,7 @@ static int
Alexei Starovoitov wrote:
On Tue, Sep 13, 2016 at 10:41:12PM +, Rustad, Mark D wrote:
That said, I can see that you have tried to keep the original code path
pretty much intact. I would note that you introduced rcu calls into the
!bpf
path that would never have been done before. While
Alexei Starovoitov wrote:
On Tue, Sep 13, 2016 at 07:14:27PM +, Rustad, Mark D wrote:
Alexei Starovoitov wrote:
On Tue, Sep 13, 2016 at 06:28:03PM +, Rustad, Mark D wrote:
Alexei Starovoitov wrote:
I've looked through qemu and it appears only emulate e1k and tg3.
The latt
Greg wrote:
Someday Linux will be a modern OS that just includes IPV6 and forces a
config option to NOT have it.
That'll be great. All the IS_ENABLED_(CONFIG_IPV6) scattered everywhere
is nuts.
Better wait until everyone at least *has* IPv6! I have yet to have IPv6
deployed on any of my
Alexei Starovoitov wrote:
On Tue, Sep 13, 2016 at 06:28:03PM +, Rustad, Mark D wrote:
Alexei Starovoitov wrote:
I've looked through qemu and it appears only emulate e1k and tg3.
The latter is still used in the field, so the risk of touching
it is higher.
I have no idea what make
Alexei Starovoitov wrote:
I've looked through qemu and it appears only emulate e1k and tg3.
The latter is still used in the field, so the risk of touching
it is higher.
I have no idea what makes you think that e1k is *not* "used in the field".
I grant you it probably is used more virtualiz
Benjamin Herrenschmidt wrote:
Filtering things to work around bugs in existing guests to avoid crashes
is a different kettle of fish and could be justified but keep in mind that
in most cases a malicious guest will be able to exploit those HW flaws.
Bugs in existing guests is an interesting c
Benjamin Herrenschmidt wrote:
We may want some kind of "strict" vs. "relaxed" model here to
differenciate the desktop user wanting to give a function to his/her
windows partition and doesn't care about strict isolation vs. the cloud
data center.
I don't think desktop users appreciate hangs an
Jarod Wilson wrote:
I've got reports that the Intel I-218V NIC in Intel NUC5i5RYH systems used
as a PTP slave experiences random ~10 hour clock jumps, which are resolved
if the same workaround for the 82574 and 82583 is employed. Switching from
an if to a select, because the list of NIC types c
Patrick McLean wrote:
Gmail mangled my first message, sorry about that. Second attempt.
In ixgbe_init_mac_link_ops_X550em, the code has a special case for
backplane media type, but does not fall through to the default case,
so the setup_fc never gets initialized. This causes a panic when it
la
Denys Vlasenko wrote:
Users report that under VMWare, er32(TIMINCA) returns zero.
This causes division by zero at init time as follows:
==>incvalue = er32(TIMINCA) & E1000_TIMINCA_INCVALUE_MASK;
for (i = 0; i < E1000_MAX_82574_SYSTIM_REREADS; i++) {
KY Srinivasan wrote:
-Original Message-
From: Rustad, Mark D [mailto:mark.d.rus...@intel.com]
Sent: Thursday, April 14, 2016 5:07 PM
To: KY Srinivasan
Cc: David Miller ; netdev
; linux-ker...@vger.kernel.org;
de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
jasow
KY Srinivasan wrote:
-Original Message-
From: Rustad, Mark D [mailto:mark.d.rus...@intel.com]
Sent: Thursday, April 14, 2016 4:01 PM
To: KY Srinivasan
Cc: David Miller ; netdev
; linux-ker...@vger.kernel.org;
de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
jasow
Some comments below:
K. Y. Srinivasan wrote:
On Hyper-V, the VF/PF communication is a via software mediated path
as opposed to the hardware mailbox. Make the necessary
adjustments to support Hyper-V.
Signed-off-by: K. Y. Srinivasan
---
drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 1
Andy Shevchenko wrote:
On Mon, Apr 11, 2016 at 6:27 PM, Sudip Mukherjee
wrote:
From: Sudip Mukherjee
We have a check for card just after dereferencing it. So if it is NULL
we have already dereferenced it before its check. Lets dereference it
after checking card for NULL.
IIUC the code doe
John Fastabend wrote:
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_model.h
b/drivers/net/ethernet/intel/ixgbe/ixgbe_model.h
new file mode 100644
index 000..43ebec4
--- /dev/null
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_model.h
@@ -0,0 +1,112 @@
+/***
Aaron F wrote:
From: Intel-wired-lan [intel-wired-lan-boun...@lists.osuosl.org] on
behalf of Stefan Assmann [sassm...@kpanic.de]
Sent: Wednesday, February 03, 2016 12:20 AM
To: intel-wired-...@lists.osuosl.org
Cc: netdev@vger.kernel.org; da...@davemloft.net; sassm...@kpanic.de
Subject: [Intel
Aaron F wrote:
From: Intel-wired-lan [intel-wired-lan-boun...@lists.osuosl.org] on
behalf of Stefan Assmann [sassm...@kpanic.de]
Sent: Wednesday, February 03, 2016 12:20 AM
To: intel-wired-...@lists.osuosl.org
Cc: netdev@vger.kernel.org; da...@davemloft.net; sassm...@kpanic.de
Subject: [Intel
Marek Vasut wrote:
I see, so adding u32 also here works. I'm starting to wonder if the BIT
macro is really that nice and if I shouldn't just use (1 << n) as usual.
Actually, (1 << n) is not so good either when n is 31 - it can trigger
overflow warnings since it will be presumed to be a sign
Alexander Duyck wrote:
There isn't any need to add such an indication, nor do we need to
start bitflipping the return value from csum_fold in all cases. I
think there was just some confusion about UDP checksums vs GRE or TCP
checksums.
Yeah. I think I finally got there. The naive software me
Alexander Duyck wrote:
Actually you may want to go the other way on that. If they weren't
flipping the checksum value for GRE before why should we start doing
that now? I'm pretty sure the checksum mangling is a very UDP centric
thing. There is no need to introduce it to other protocols.
I
zyjzyj2...@gmail.com wrote:
> From: Zhu Yanjun
>
> According to the suggestion from Rustad, Mark D, this behavior perhaps
> is more related to the copper phy. But to make fiber phy more robust,
> to all the interfaces as a slave interface, the link_speed and link_up
&g
Emil S wrote:
>> */
>> -if (hw->mac.type == ixgbe_mac_X540)
>> +if ((hw->mac.type == ixgbe_mac_X540) &&
>> +(netdev->flags & IFF_SLAVE))
>> if (link_speed == IXGBE_LINK_SPEED_UNKNOWN)
>> return;
>
> If you were to enter ixgbe_watchdog_link_is_up
Maciej Żenczykowski wrote:
> I'd tend to agree that reset or abort would be preferable to destroy.
> After all... the socket doesn't actually go away.
Or maybe terminate? Reset kind of implies to me that it may resume operation.
Abort could be ok. I think terminate is somewhat more neutral, if
Edward Cree wrote:
> I have just realised something startling. Assuming the inner protocol uses
> the ones complement checksum in the way IP, UDP and TCP do, the outer
> checksum can be computed *without looking at the payload*. Why? Because the
> ones complement sum of (say) a correctly ch
Otto Sabart wrote:
> I probably found a performance regression on ixgbe (Intel 82599EB
> 10-Gigabit NIC) on v4.4-rc3. I am able to see this problem since
> v4.4-rc1.
>
> The bug report you can find here [0].
>
> Can somebody take a look at it?
>
> [0] https://bugzilla.redhat.com/show_bug.cgi?i
Alexander Duyck wrote:
> This doesn't look right. How come this doesn't match the implementation you
> did for the ixgbevf driver? If I am not mistaken this approach had issues
> where it could spin forever didn't it?
Yes, this is the original version of the patch instead of the V4 of the pa
Joe Perches wrote:
> On Wed, 2015-11-25 at 02:46 -0800, Jeff Kirsher wrote:
>> On Tue, 2015-11-24 at 16:43 -0800, Joe Perches wrote:
>>> On Tue, 2015-11-24 at 16:04 -0800, Jeff Kirsher wrote:
From: Helin Zhang
Pointer of type void * shouldn't be used in arithmetic, which may
Tom Herbert wrote:
> The skb_csum_offload_chk is used to resolve checksums that are unable
> to be offloaded to the device.
>
> Signed-off-by: Tom Herbert
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 41 +++
> 1 file changed, 29 insertions(+), 12 deletions(-)
>
William,
Emil S wrote:
>> It also fixes my issue: even if eth{2,3} are still up with no carrier, I
>> don't have any kworker in D state.
>
> It appears that you have 2 ports with empty cages. If that is the case there
> is no reason to keep the interfaces up. If you bring them down, or plug the
Nicholas Krause wrote:
> This fixes error handling in the function fm10k_setup_tc to properly
> check if the call to the function fm10k_open has failed by returning
> a error and if so return immediately to the caller of the function
> fm10k_setup_tc to properly signal this non recoverable failur
Jiri Pirko wrote:
>>> + int (*port_init)(struct rocker_port *rocker_port, void *priv,
>>> +void *port_priv);
>>
>> Yuck, void *. Can we do better?
>
> I see nothing wrong with this priv usage. It's done like this on many
> places. I think it is completely legit, s
> On Oct 5, 2015, at 9:23 AM, Tom Herbert wrote:
>
> 4) To help drivers for devices with limited offload capabilities we'll
> define a helper function to check for typical restrictions (.e.g. IPv4
> only, TCP/UDP only. no encapsulation, no IPv6 extension headers,
> etc.). I am working on this hel
> On Sep 29, 2015, at 3:39 PM, Joe Stringer wrote:
>
> @@ -728,8 +727,14 @@ static void ovs_fragment(struct vport *vport, struct
> sk_buff *skb, u16 mru,
> WARN_ONCE(1, "Failed fragment ->%s: eth=%04x, MRU=%d, MTU=%d.",
> ovs_vport_name(vport), ntohs(etherty
> On Sep 15, 2015, at 2:17 PM, Alex Williamson
> wrote:
>
> Also, rather than clearing the flag, can we move the tests done by
> pci_vpd_f0_dev_check() into the
> quirk setup function? It seems like function 0 should be sufficiently
> configured by the time we're probing non-zero functions that
> On Sep 15, 2015, at 12:04 PM, Alex Williamson
> wrote:
>
>
> FRU-type information is only one of the use cases of VPD, the spec also
> defines (PCI rev 3.0, 6.4):
>
>... a mechanism for storing information such as performance and
>failure data on the device being monitored.
>
> On Sep 15, 2015, at 11:19 AM, Alex Williamson
> wrote:
>
> In addition to the (PCI_SLOT() != devfn) issue, I'm concerned about
> topologies like we see on Skylake. IIRC, the integrated NIC appears at
> something like 00:1f.6. I don't know if that specific NIC has VPD, nor
> am I sure it real
> On Sep 9, 2015, at 9:07 PM, Jarod Wilson wrote:
>
> diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
> b/drivers/net/ethernet/intel/igb/igb_main.c
> index e174fbb..a5e0022 100644
> --- a/drivers/net/ethernet/intel/igb/igb_main.c
> +++ b/drivers/net/ethernet/intel/igb/igb_main.c
> @@ -282
> On Sep 7, 2015, at 4:02 AM, David Laight wrote:
>
> Feed:
> int bar(int (*f)[10]) { return sizeof *f; }
> into cc -O2 -S and look at the generated code - returns 40 not 4.
Yes, indeed it does. And with clang too. I guess I was too easily discouraged
when looking for a workable syntax some yea
> On Sep 4, 2015, at 2:07 AM, David Laight wrote:
>
>> I find them useful as syntactic sugar. We have not used them a lot, but
>> there are cases in our crypto
>> handling code where we have fixed size array inputs/outputs and there we
>> opted to use them. They make
>> it easy to remember what
> On Sep 2, 2015, at 4:21 PM, Tom Herbert wrote:
>
> Mark, another question in this area of code. Looking at ixgbe_tx_csum,
> I'm wondering what happens with those default cases for the switch
> statements. If those are hit for whatever reason does that mean the
> checksum is never resolved? It s
> On Sep 1, 2015, at 8:31 PM, Tom Herbert wrote:
>
>> @@ -7240,6 +7267,10 @@ static void ixgbe_atr(struct ixgbe_ring *ring,
>>struct ipv6hdr *ipv6;
>>} hdr;
>>struct tcphdr *th;
>> + struct sk_buff *skb;
>> +#ifdef CONFIG_IXGBE_VXLAN
>> + u8 encap = fal
> On Sep 1, 2015, at 8:17 PM, Tom Herbert wrote:
>
> I suspect this is not UDP-encapsulation specific, will it work with
> TCP/IP/IP, TCP/IP/GRE etc.?
It could do more, but this is what has been tested up to this point.
> Isn't there anyway the ixgbe could just be made to NETIF_HW_CSUM? That
>
> On Aug 18, 2015, at 1:33 PM, Jiri Benc wrote:
>
> Signed-off-by: Jiri Benc
> ---
> drivers/net/vxlan.c | 8
> include/net/vxlan.h | 5 +
> 2 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
> index e4b8ab63d0fa..d5ca1d7e0b81
> On Jul 23, 2015, at 5:03 PM, Scott Feldman wrote:
>
> On the CHECKs on space after cast, should we modify checkpatch.pl to
> not flag those for drivers/net?
Please don't. My internal parser really wants to see the cast right up against
whatever it is casting. Has this practice been changing a
> On Jul 15, 2015, at 9:49 AM, Rustad, Mark D wrote:
>
>> On Jul 15, 2015, at 8:12 AM, Vadim Kochan wrote:
>> Would you please check this fix ?
>>
>> diff --git a/misc/ss.c b/misc/ss.c
>> index 03f92fa..3a826e4 100644
>> --- a/misc/ss.c
>> +++
> On Jul 15, 2015, at 8:12 AM, Vadim Kochan wrote:
> Would you please check this fix ?
>
> diff --git a/misc/ss.c b/misc/ss.c
> index 03f92fa..3a826e4 100644
> --- a/misc/ss.c
> +++ b/misc/ss.c
> @@ -683,8 +683,8 @@ static inline void sock_addr_set_str(inet_prefix *prefix,
> char **ptr)
>
> sta
> On Jun 26, 2015, at 11:04 AM, Rustad, Mark D wrote:
>
>> Sorry, Mark, I've just been busy with other issues and haven't had a
>> chance to look at this yet.
>
> Is there any chance of this getting into this merge window?
Well, it has missed the merge wi
> On Jun 17, 2015, at 9:44 AM, Bjorn Helgaas wrote:
>
> On Wed, Jun 17, 2015 at 11:29 AM, Rustad, Mark D
> wrote:
>> + Alex
>>
>>> On Jun 5, 2015, at 2:59 PM, Rustad, Mark D wrote:
>>>
>>>> On Jun 3, 2015, at 11:46 AM, Mark D Rustad
+ Alex
> On Jun 5, 2015, at 2:59 PM, Rustad, Mark D wrote:
>
>> On Jun 3, 2015, at 11:46 AM, Mark D Rustad wrote:
>>
>> Many multi-function devices provide shared registers in extended
>> config space for accessing VPD. The behavior of these registers
>>
> On Jun 3, 2015, at 11:46 AM, Mark D Rustad wrote:
>
> Many multi-function devices provide shared registers in extended
> config space for accessing VPD. The behavior of these registers
> means that the state must be tracked and access locked correctly
> for accesses not to hang or worse. One wa
> On Jun 2, 2015, at 7:28 PM, Alexander Duyck wrote:
>
> You can probably combine the dev->multifunction check with the dev_flags
> check. After all you don't need this workaround if the device is not
> multifunction. It might even make more sense to move the multifunction check
> to the qui
> On Jun 2, 2015, at 10:48 AM, Alexander Duyck
> wrote:
>
> I'm pretty sure these could cause some serious errors if you direct assign
> the device into a VM since you then end up with multiple devices sharing a
> bus. Also it would likely have side-effects on a LOM (Lan On Motherboard) as
>
> On May 27, 2015, at 10:27 AM, Bjorn Helgaas wrote:
>
> It sounds like there are real problems here that would be fixed by changing
> the mutex strategy and limiting VPD read lengths, but that we don't quite
> have consensus on how to solve them yet.
I have a new pair of patches that I am getti
> On May 19, 2015, at 6:02 PM, Alexander Duyck
> wrote:
>
> My suspicion is that we have a number of bugs floating around out there like
> the Broadcom issue. Specifically, one of the ones I found was that the r8169
> seems to have a similar issue as called out in the email thread at
> http:
> On May 19, 2015, at 2:17 PM, Alexander Duyck
> wrote:
>
> Any chance you could point me toward the software in question? Just
> wondering because it seems like what you are fixing with this is an
> implementation issue in the application since you really shouldn't be
> accessing areas outs
> On May 19, 2015, at 10:50 AM, Alexander Duyck
> wrote:
>
> These two patches are very much related.
They are only related because I saw an opportunity to do this while working on
the other issue. That is the only relationship.
>>> Artificially limiting the size of the VPD does nothing but
73 matches
Mail list logo
